Issue 22827 - Deprecate 128-bit cent and ucent types

[ibuclaw]

Pave the way for making an exit for these types in the compiler.

After removal both can be moved to be aliases in the object module.

Actually issuing a deprecation message in the parser would break everyone, and keeping the error in the semantic makes it consistent with the deprecation->error path for complex numbers.

[dlang-bot]

Thanks for your pull request, @ibuclaw!

Bugzilla references

Auto-close	Bugzilla	Severity	Description
✗	22827	normal	Deprecate 128-bit cent and ucent types

Testing this PR locally

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

dub run digger -- build "master + dmd#13730"

[ljmf00]

Are we removing those built-ins from the language? Will we reserve these keywords for future use?

[ibuclaw]

Are we removing those built-ins from the language? Will we reserve these keywords for future use?

There are no 128-bit built-ins in the language. As for the keywords, they have always been reserved. The keywords aren't going to stop being reserved. The reservation of them just may not necessarily be done by the compiler (i.e: an alias in the object module).

[ljmf00]

Are we removing those built-ins from the language? Will we reserve these keywords for future use?

There are no 128-bit built-ins in the language. As for the keywords, they have always been reserved. The keywords aren't going to stop being reserved. The reservation of them just may not necessarily be done by the compiler (i.e: an alias in the object module).

So the plan is to do alias cent = Cent; on the object.d?

[ibuclaw]

So the plan is to do alias cent = Cent; on the object.d?

I can't see any reason why not to. Ditto complex numbers too (alias creal = __c_complex_real;).

[ljmf00]

So the plan is to do alias cent = Cent; on the object.d?

I can't see any reason why not to. Ditto complex numbers too (alias creal = __c_complex_real;).

Cool. So since this is already an error and, realistically, no D compiler implements cent (which is reserved in the spec, but with a defined behaviour), we don't need to deprecate this or at least have a long deprecation process for this keyword?

[ibuclaw]

10 releases follows the process of DIP1013. Yeah, this is an edge case, where we're just changing an error to a more informative one that directs people to a library solution. I'd still prefer to wait a while, and give time to iron out the library implementation before removing support from the compiler proper.

[ljmf00]

10 releases follows the process of DIP1013. Yeah, this is an edge case, where we're just changing an error to a more informative one that directs people to a library solution. I'd still prefer to wait a while, and give time to iron out the library implementation before removing support from the compiler proper.

I think applying the deprecation process here is a bit weird and unnecessary, but, strictly speaking, sure, it should be that way. Perhaps, GDC implements cent and ucent?

I mean, my whole point is that we are deprecating an error, when the deprecation process ends we deprecate the error to a non-error? This, in particular, doesn't affect the end-users and, if we transit to an alias, the feature behaves exactly how it should.

If GDC implements this type as built-in on a stable release, I think this makes sense, otherwise, if there is no real D compiler implementing it, I think this is a bit unnecessary.

[RazvanN7]

I got here through #13506 and didn't see the labels (needs changelog, needs spec PR). This was an error anyway so I did not hesitate to merge. However, do we really need a changelog and a spec entry for this?

[ibuclaw]

@RazvanN7 the spec (probably the deprecate.dd page) should have an entry for completeness sake.

[ibuclaw]

dlang/dlang.org#3247