Evolving the D Language

[IchorDev]

On Friday, 7 July 2023 at 03:06:28 UTC, Walter Bright wrote:
> As time moves on, the D language has to evolve as well. What do 
> we do with obsolete and/or problem-causing, legacy features?
>
> Our answer was deprecation. The deprecation starts out as just 
> a message, which can be disabled, or can be set to be errors. 
> The deprecations could last for many years, then become errors, 
> but with a "-revert" switch if one still wanted to use them.
>
> I thought that was a straightforward approach, giving people 
> many years to modernize their code.
>
> I was wrong. I heard you. We're going to have to change course.
>
> [...]

This is an interesting decision indeed. However, definitely I 
agree with Rikki that it should be opt-in, rather than opt-out.

> Your thoughts and advice are appreciated. Feel free to add this 
> thread your wish lists on legacy feature resurrection that 
> should have priority. Or if you've got a better idea, let us 
> know!

Hexstring literals, complex and imaginary floating point types & 
the corresponding literals, built-in 128-bit integer types, and 
octal literals, I think could all be added back to D without 
causing much detriment to D users who don't want to use them. For 
people who do use them, they're very useful to have.
I'm not sure how open you are to tweaking legacy features 
slightly, but here are some suggestions in case that's on the 
table:
1. I think adapting `std.int128.Int128` to make `cent`/`ucent` 
functional for the sake of simpler BetterC code would be really 
lovely. Much nicer than having to create custom wrappers over 
`core.int128.Cent`...
2. Ideally octal literals would have a better syntax. (e.g. 
"0o123")