On Friday, 7 July 2023 at 13:19:51 UTC, Nick Treleaven wrote:
Changing the syntax just for an obsolete feature would send the
wrong message.
[...]
cent and ucent are already an error as of 2.100. Were they even
implemented?
Clearly you're not looking at this the same way as me, [or
Walter](https://github.com/dlang/dmd/pull/15393).
Fixing old code isn't the only upside to resurrecting old
features.
First thing, I think all languages should support binary, octal,
decimal and hexadecimal literals as a baseline. Octal is probably
the least important of them, but can still be plenty useful in
its own right. You technically don't need *any* numerical
literals at all in D, you could make all of them with
string-to-number templates. You could take such an approach to
just about everything in D, actually! On the other hand, people
working on low-level Linux code might be pretty appalled to find
out that they can't simply use octal literals to represent file
permissions in D.
Second, I think re-examining and sometimes resurrecting features
that were removed from D, no matter how long ago, is important.
Think about it this way, the only reason D doesn't have octal
literals right now is because when it did have octal literals the
syntax was ambiguous. The solution at the time was removing them
from the language, but had their syntax been modified at the time
then they wouldn't have been ambiguous. Who says it's too late?
There are a few D features that were poorly implemented (or not
implemented at all), and then simply removed instead of being
fully reconsidered. You might say that for many, they were indeed
reconsidered, and then added to Phobos instead. Now some of these
features pre-date BetterC, of course, but I am a regular BetterC
user. A feature being moved to Phobos translates to "you don't
get to use this in most of your code anymore" for me. I'm not a
user of complex or imaginary types, but I don't see why they
needed to be removed from D, were they a huge burden to maintain
compared to being in Phobos?
TL;DR I think we should be more lenient about leaving features in
the language if they aren't in the way, and consider ways of
modifying them rather than removing them from the language if
they get in the way.
