Hi,

Sincerely I am tired to maintain my library with every change made by D compiler. Mostly regressions. Bug reports are ignored or challenged, I don't have time to argue.

Therefore, if someone finds interesting my decimal lib [0], please continue or maintain it from here, I stopped completely to adjust it. It is still working, but unit tests are not running anymore because of regressions in compiler.

The last issues are generated by unpublished changes in the parser:

Examples:

float z = 85886696878585969769557975866955695.E0; //integer overflow, I don't see any int
real x = 0x1p-16383; //number `0x1p-16383` is not representable. It is, trust me.

Please don't ask me what is the last version when everything worked like a charm. I don't know and now I don't care.

[0] https://github.com/rumbu13/decimal

On 8/5/22 11:36 AM, Rumbu wrote:

That's an integer, which is trying to call a UFCS function named E0. Did you mean to include the .?

-Steve

On Friday, 5 August 2022 at 15:44:10 UTC, Steven Schveighoffer wrote:

Yes, continue to argue, exactly what I am saying. It worked before because numbers were eagerly consumed in the parser. Someone made a change without dovumenting it. That value is not even written by me, it is from an official test file from Intel which should be parsed by any C compiler. Since there are millions of tests there, I don't intend to hand pick the values from the file to make D compiler happy.

Hi Rumbu,

I appreciate your work.

On Friday, 5 August 2022 at 15:36:06 UTC, Rumbu wrote:

float z = 85886696878585969769557975866955695.E0; //integer

The latest compiler here on my local machine is 2.073.2 of 2017 (?):

$ dmd --version
DMD64 D Compiler v2.073.2
Copyright (c) 1999-2016 by Digital Mars written by Walter Bright
$ cat e0.d
unittest {
   float z = 85886696878585969769557975866955695.E0; //integer overflow, I don't see any int
   real x = 0x1p-16383; //number `0x1p-16383` is not representable. It is, trust me.
}
$ dmd e0
e0.d(2): Error: integer overflow
e0.d(3): Error: number '0x1p-16383' is not representable

On 8/5/22 11:57 AM, React wrote:

Just saying, I see an integer. That's an integer according to the language (as far back as I can test, which is 2.060 released 2012). If that was somehow parsing as a float before, that was a bug in the parser. Since your first release is 0.9, released Jan 2018, I find it hard to believe this ever worked for you.

D is not a C compiler. Well it has an experimental one, but that shouldn't be relied on for testing.

-Steve

On Friday, 5 August 2022 at 15:44:10 UTC, Steven Schveighoffer wrote:

Either drop the . or drop the E.

On Friday, 5 August 2022 at 16:08:50 UTC, Steven Schveighoffer wrote:

Yes, I am lying, my hidden agenda is to put D in a bad spot. Congrats, you got me.

On 8/5/22 12:30 PM, Rumbu wrote:

I don't have any agenda or want to bust yours. D is not in a bad spot since code that is not D code is not (and has never been) expected to compile.

I don't think that code ever built. Possibly you didn't test it properly originally. But if you are done with it, I guess it doesn't matter.

-Steve

On Friday, 5 August 2022 at 16:30:28 UTC, Rumbu wrote:

If you pull up run.dlang.org and run the code below with "All D compilers" (which goes back to 2.060) you can see what the error messages would have been. As I said above, if you remove the . or the E then it should have run fine (the server might time out with all compilers, but you can run it with the current version just fine). It is entirely possible that you have a typo in your code that is causing the issue and what you looked at previously didn't have the typo. No hidden agenda needed.

void main()
{
    double x = 85886696878585969769557975866955695.E0;
}

On Friday, 5 August 2022 at 15:44:10 UTC, Steven Schveighoffer wrote:

Both "123." and "123.E123" is valid C. For some reason, D only copied the former.