David Heffernan

Now you are talking about the generated code. Which is a different issue. Hitherto there has been a long, and in my view bogus, discussion about compilation speed. The OP said that compilation speed was a reason to prefer avoiding typed constants. The point that I made which seems to have generated such noise is merely that speed of compilation is no reason to prefer true constants over typed constants. EDIT: I didn't read closely enough. You are claiming that the compile time must be longer because more instructions are emitted? Wow, that's weird. Known to be false also. Consider optimisation. Often this results in fewer instructions emitted, post optimisation. But optimisation is an additional step that can increase compile time There are good reasons to prefer true constants over typed constants. Compilation speed isn't one of them. Efficiency of generated code is one. Frankly I'm ambivalent about what you both think. If you want to change the way you code to save a couple of milliseconds of each compilation, then do it. It doesn't bother me.

Only for a totally unrepresentative example, and only because of implementation defects in that compiler. Not because there is anything conceptual. Feel free to choose between true and typed constants because of a few milliseconds difference in compilation time. If that means something to you, great. Knock yourself out. For me I will stick to what results in readable and maintainable code, and code that runs most efficiently.

And your code showed that they don't.

My point is that the difference in compilation time is insignificant, and absolutely should not drive your choices of how to write the code. Certainly for the DLL that I ship, that's not the case. The time spent fixing up symbols isn't great because there aren't that many.

Colours aren't hex. Hex is just a different way to write an integer, using base 16. For instance $10=16.

That's clearly a deficiency in the x64 compiler implementation since the x86 compiler doesn't suffer the problem. The x86 compiler demonstrates that the difference in performance is not due to a fundamental conceptual hurdle, but a poor implementation. We know that the x64 compiler performs very poorly. In any case the test is totally unrealistic. You aren't going to encounter this in real world code.

Show me some evidence based on measurements.

As I said, when I need to take the address. An example from my code base is when calling external code, written in Fortran, that expects values to be passed by reference always. You do. If you can't provide a real world example where compilation time is significantly impacted, then I call BS. I'm talking about the language as it stands today. Your original post was too.

The fact that you've never come across a need for taking the address of a constant doesn't mean the need doesn't exist. How about asking why this need arises rather than thinking you've seen all possible use cases for typed constants.

I didn't see the part where you measured compile times. It is true. We're talking about Delphi. We're not talking about some potential other language.

Conclusions seem bogus to me. I don't think the compilation speed is a factor, and there are plenty of times when you use typed constants for integers. The rules really should be: 1. Use true constants if possible. 2. Otherwise use a typed constant. The factors that force you to use typed constants are broadly because the type is a complex type which doesn't permit true constants. Or you need to take the address of the constant.

Wait a minute. If its a 64 bit add in then why are you casting the pointer to a 32 bit integer?

I highly doubt that wordID or hdl are really THandle. The latter should be HWND. Not sure what the former should be. THandle represents a kernel handle. It's something that you would call CloseHandle on. As for your problem, hard to know. Could be UIPI. You don't do any error checking when you call SendMessage. You need to add some trace debugging.

Couldn't take the traffic of tens of devs trying to vote for range checking enabled by default

Let's start by establishing whether or not there is a problem that cannot be worked around. Which integer value are you unable to declare as a literal?

I have a question for you. Which integer value are you unable to declare as a literal?

It's more nuanced. Assign it to a single variable, and it's just a 4 byte assignment. At least that's how it always has been for floating point literals. Its type is only really crystallised then you assign it is how you might think about it.

FWIW, const C = Single(0.1) does not compile in XE7 which is my day to day Delphi. And it does in 10.3 and possibly earlier versions too. Which would appear to provide a way to specify the type of floating point literal when the value is not exactly representable. I'd prefer to use a suffix rather than a type, but the precedent was set by integer types. So, no, I don't see any unsurmountable problems here.

I don't think the issue is that I don't see the full picture and have a lack of clarity.

As far as I am concerned the only issue raised in this thread that can't be worked around is the type of floating point literals. Integer literals can be cast. But not floating point literals. Having said that, my recollection is that `Single(0.1)` would not compile so I wonder if there has been a change since XE7, the version I am most familiar with.

The inability to control the type of a floating point literal is the only real issue here. Everything else mentioned above can be readily worked around. But the fact that you can't control the type of a floating point literal presents problems that have no workaround. I want to write const s = 0.1s; d = 0.1d; And have two literals with different values.

They should be, don't know why Emba doesn't do this

You should enable both range checking and overflow checking. Then you'll see your exceptions.

The actual bug could be in eithsr of these plugins, or another plugin, or the IDE itself.

Curious, but why would here be VCL and FMX versions of Delete File? Isn't it an RTL function?