Ghosting a language feature

[Mathias LANG]

On Monday, 21 September 2020 at 02:43:57 UTC, Walter Bright wrote:
> On 9/20/2020 7:38 PM, Avrina wrote:
>> why not just remove it so no one uses it.
>
> Because legacy code will use it. Removing features has been a 
> constant source of irritation to users, and they're right.

I wish D would stop trying to be this or that, and finally settle 
on its identity.

People that use D don't do it because they want a flawless 
upgrade path and everything to just be the same 10 years from 
now. If you want this, you just stick with one of the big 
languages. This is not just an hypothesis out of thin air, look 
at the community survey: 
https://rawgit.com/wilzbach/state-of-d/master/report.html
Grep for "What is your tolerance for stability vs. breaking 
changes". Provided the question is biased, but still, the answers 
lean heavily in one direction.

But still, people complain. And many core contributors, myself 
included, will heavily weight against breaking change. So why the 
apparent disconnect ?
Once again, the person that managed to put it together best was 
Don Clugston. He mentioned it in his talk @ DConf 2013.

It's exactly 5 minutes, starting from here: 
https://youtu.be/pmwKRYrfEyY?t=1838

Now, the example that Don used, implicit fallthru, was a win for 
Sociomantic. But what if there was no bug ? If there was only a 
handful occurrences, none of them buggy ? Then they would really 
pay a cost for nothing. A small cost, but a cost nonetheless.

I hit a similar case a few years ago, when I deprecated using the 
return of the comma operator. To my surprise, there were quite a 
few users. Even more surprising, after looking at the way this 
feature was used, it **made perfect sense**. In the particular 
situations, reading the code, using the return of a comma 
expression  was... Neat. And here I was, asking those people to 
change their neat code because I thought it was wrong and led to 
issues such as `synchronized(a, b)`.

Well turns out, D has one of the most powerful tool to deal with 
this: "deprecated".
Deprecating something, and giving a decent timeframe, allows to 
move things forward without destroying the ecosystem. It gives 
the weary programmer a way to ignore a few annoying deprecations 
in his/her code when all that programmer's want to do is enjoy 
the new features in the latest release. It gives times for 
everyone, including dependency, to tackle the problem, at the 
minor inconvenience of a little message.

We've been refining deprecated for years. When it started, you 
could only apply it on functions, and no message was allowed. 
Then we added support for string literal. Then one day Vibe.d 
broke because of a stray import to an empty Phobos module, and we 
added support for deprecated module. Then CTFE-able messages. 
Along the way, we made sure that one could access deprecated code 
within a deprecated scope, so a library can keep providing the 
same functionality to users without breaking compatibility. And 
with D's amazing feature set, a library can even use `static if 
(__VERSION__ >= 2094)` to deprecated based on the compiler used.

Did you know that `deprecated` is so amazing that it's the 
feature that Sociomantic **backported to D1** ? That's right, 
this feature is so awesome that Sociomantic decided they needed 
it more than any other D2 features, because of how much it 
simplified internal libraries updates. And it had amazing ROI.

In conclusion, I simply hope we keep on putting more 
consideration into why people come to D, as opposed to why people 
say they won't. And people come to D not for a language that has 
eternal backwards compatibility, because one simply can use C++ 
for this.