On 8/6/2022 2:02 AM, Tim wrote:
> It could silently break code if the right function is defined. The following example is valid in C and D (except import/include), but prints a different value:
> 
> ```D
> // #include <stdio.h>
> import core.stdc.stdio;
> 
> int E2(int i)
> {
>      return i;
> }
> 
> int main()
> {
>      float f = 123.E2;
>      printf("%f\n", f);
>      return 0;
> }


Congrats, you got me there!

On Saturday, 6 August 2022 at 08:29:19 UTC, Walter Bright wrote:
> On 8/5/2022 9:43 AM, Max Samukha wrote:
>> Both "123." and "123.E123" is valid C. For some reason, D only copied the former.
>
> It's to support UFCS (Universal Function Call Syntax).

UFCS could still be supported with the exception of functions named like exponents. (I am not advocating for it.)

> aaaand, the truth comes out. It is not representable, it is truncated to 0. Technically, ImportC should accept it. But if it does, doesn't it mislead users into thinking it is non-zero?
>
> We've got the right choice here, but it's definitely a judgement call.

No objections to this.

On Saturday, 6 August 2022 at 11:08:05 UTC, Max Samukha wrote:
> On Saturday, 6 August 2022 at 08:29:19 UTC, Walter Bright wrote:
>> On 8/5/2022 9:43 AM, Max Samukha wrote:
>>> Both "123." and "123.E123" is valid C. For some reason, D only copied the former.
>>
>> It's to support UFCS (Universal Function Call Syntax).
>
> UFCS could still be supported with the exception of functions named like exponents. (I am not advocating for it.)
>
>> aaaand, the truth comes out. It is not representable, it is truncated to 0. Technically, ImportC should accept it. But if it does, doesn't it mislead users into thinking it is non-zero?
>>
>> We've got the right choice here, but it's definitely a judgement call.
>
> No objections to this.

May be we need some warnings about ambiguity, but incompability with C in base things, as literals is not an option.

Same code compiled different with ImportC but not D, ough.

On 8/6/2022 4:08 AM, Max Samukha wrote:
> UFCS could still be supported with the exception of functions named like exponents. (I am not advocating for it.)

We could, and enter the inevitable bug report from the baffled user who can't figure out why UFCS stopped working for his algorithm-generated function names.

At some point, we just have to accept there's going to be a compromise.

On Saturday, 6 August 2022 at 08:29:19 UTC, Walter Bright wrote:
> On 8/5/2022 9:43 AM, Max Samukha wrote:
>> Both "123." and "123.E123" is valid C. For some reason, D only copied the former.
>
> It's to support UFCS (Universal Function Call Syntax). The idea with C compatible aspects of D is to not *silently* break code when there's a different meaning for it. And so, these generate an error message in D (although the error message could be much better).
>
> So, does it work with ImportC?
>
> test2.c:
>   float z = 85886696878585969769557975866955695.E0;
>   long double x = 0x1p-16383;
>
> dmd -c test2.c
>   test2.c(3): Error: number `0x1p-16383` is not representable
>

It is. Since real exponent is biased by 16383 (15 bits), it is equivalent of all exponent bits set to 0. Probably it looks unimportant, but here it was about a floating point library. Subnormal values are part of the floating point standard.

> So the first one does compile as expected with ImportC. Let's try gcc and clang:
>
> gcc -c test2.c
>   test2.c:3:1: warning: floating constant truncated to zero [-Woverflow]
>    long double x = 0x1p-16383;
>    ^
>
> clang -c test.c
>   test2.c:3:17: warning: magnitude of floating-point constant too small for type 'double'; minimum is 4.9406564584124654E-324 [-Wliteral-range]
>   long double x = 0x1p-16383;
>

Both gcc and clang are using 64 bits for long double by default. You need specific compiler flags to enable 80-bit (-mlong-double-80). Also the value needs a L suffix in clang to not be interpreted a classic double. Yes, it is truncated to 0, but is representable.

On 8/6/22 19:27, Rumbu wrote:
> On Saturday, 6 August 2022 at 08:29:19 UTC, Walter Bright wrote:
>> On 8/5/2022 9:43 AM, Max Samukha wrote:
>>> Both "123." and "123.E123" is valid C. For some reason, D only copied the former.
>>
>> It's to support UFCS (Universal Function Call Syntax). The idea with C compatible aspects of D is to not *silently* break code when there's a different meaning for it. And so, these generate an error message in D (although the error message could be much better).
>>
>> So, does it work with ImportC?
>>
>> test2.c:
>>   float z = 85886696878585969769557975866955695.E0;
>>   long double x = 0x1p-16383;
>>
>> dmd -c test2.c
>>   test2.c(3): Error: number `0x1p-16383` is not representable
>>
> 
> It is. Since real exponent is biased by 16383 (15 bits), it is equivalent of all exponent bits set to 0. Probably it looks unimportant, but here it was about a floating point library. Subnormal values are part of the floating point standard.

Seems you should just use a long double/real literal?

real x = 0x1p-16383L; // (works)

On 8/6/2022 1:29 PM, Timon Gehr wrote:
> Seems you should just use a long double/real literal?
> 
> real x = 0x1p-16383L; // (works)

Looks like that settles it. (Why didn't I notice that? Sheesh!)

On 07/08/2022 10:45 AM, Walter Bright wrote:
> On 8/6/2022 1:29 PM, Timon Gehr wrote:
>> Seems you should just use a long double/real literal?
>>
>> real x = 0x1p-16383L; // (works)
> 
> Looks like that settles it. (Why didn't I notice that? Sheesh!)

Needs a better error message.

https://issues.dlang.org/show_bug.cgi?id=23284