Fix 20449 - integer literal specification and implementation differs

[dkorpel]

This is assuming we want to adjust the implementation to conform to the spec, and not the other way around.

[dlang-bot]

Thanks for your pull request and interest in making D better, @dkorpel! We are looking forward to reviewing it, and you should be hearing from a maintainer soon.
Please verify that your PR follows this checklist:

• My PR is fully covered with tests (you can see the coverage diff by visiting the details link of the codecov check)
• My PR is as minimal as possible (smaller, focused PRs are easier to review than big ones)
• I have provided a detailed rationale explaining my changes
• New or modified functions have Ddoc comments (with Params: and Returns:)

Please see CONTRIBUTING.md for more information.

---

If you have addressed all reviews or aren't sure how to proceed, don't hesitate to ping us with a simple comment.

Bugzilla references

Auto-close	Bugzilla	Severity	Description
✓	20449	normal	integer literal specification and implementation differs

Testing this PR locally

If you don't have a local development environment setup, you can use Digger to test this PR:

dub fetch digger
dub run digger -- build "master + dmd#10673"

[Geod24]

Just remove this line then ?

[ghost]

What about auto x = 9223372036854775808L;? Will this compile in the new version?

According to the specs it shouldn't, but it feels a little bit strange to me that adding an L suffix reduces the amount of accepted values.

[Geod24]

According to the specs it shouldn't, but it feels a little bit strange to me that adding an L suffix reduces the amount of accepted values.

L is asking for a type explicitly. It's a bit redundant with auto x = long(value);, but that syntax is only available since a few years while the suffix approach dates back from C.
So if you ask for a type but the argument you provide does not fit in, it makes sense that the compiler errors out, doesn't it ?

[ghost]

L is asking for a type explicitly.

Does it? It could also be seen, that this literal uses 64 bits and not only 32.

Anyway, I just wanted to point out, that there might be a problem. For me, the fix is fine.

[WalterBright]

Because it's been implemented this way for 19 years now, and the compiler behavior matches C, I recommend that the spec change rather than the compiler.

[WalterBright]

I changed the bugzilla issue to be a spec bug rather than a compiler bug.