Is it time for D 3.0?

[Istvan Dobos]

On Friday, 27 March 2020 at 15:56:40 UTC, Steven Schveighoffer 
wrote:
> There have been a lot of this pattern happening:
>
> 1. We need to add feature X, to fix problem Y.
> 2. This will break ALL CODE IN EXISTENCE
> 3. OK, cancel the fix, we'll just live with it.
>
> Having a new branch of the compiler will provide a way to keep 
> D2 development alive while giving a playground to add new 
> mechanisms, fix long-existing design issues, and provide an 
> opt-in for code breakage.
>
> Some issues I can think of:
>
> 1. The safe by default debate
> 2. pure by default
> 3. nothrow by default
> 4. String interpolation DIP
> 5. auto-decoding
> 6. range.save
> 7. virtual by default
> 8. ProtoObject
>
> Other languages evolve much quicker than D, but break things 
> only in major updates. D seems to "sort of" break things, 
> there's always a risk in every release. We try to be 
> conservative, but we have this horrible mix of deciding some 
> features can break things, while others are not allowed to, and 
> there's no clear guide as to which breakage fits in which 
> category.
>
> If we went to a more regular major release schedule, and 
> decided for a roadmap for each major release what features 
> would be included, it would allow much better planning, and 
> much more defensible breakage of code. If you know that your 
> code will only compile with D2.x, and you're fine with that, 
> then great, don't upgrade to D3.x. If you desperately want a 
> feature, you may have to upgrade to D3.x, but once you get 
> there, you know your code is going to build for a while.
>
> We could also not plan for many major releases, but at least 
> move to D3 for some major TLC to the language that is held back 
> to prevent breakage.
>
> I work occasionally with Swift, and they move very fast, and 
> break a lot of stuff, but only in major versions. It's a bit 
> fast for my taste, but it seems to work for them. And they get 
> to fix issues that languages like C++ might have been stuck 
> with forever.
>
> The biggest drawback is that we aren't a huge language, with 
> lots of manpower to keep x branches going at once.
>
> I just wanted to throw it out as a discussion point. We spend 
> an awful lot of newsgroup server bytes debating things that to 
> me seem obvious, but have legitimate downsides for not breaking 
> them in a "stable" language.
>
> -Steve

I agree with the general idea of introducing breaking changes in 
an organised way.
I didn't write a massive amount of D, but in light of its 
brilliant features, sticking so rigidly to C and C++ seems like 
an idea that inherited difficulties from them meanwhile failing 
to reap the benefits. The great features which make you all 
gather here deserve to break free!
Fortunately now seems to be a historical moment when C 
syntax/semantics does no longer need to be a given, as more 
languages gain traction that purposefully break away from them. 
(For the better, I think.)
It does not matter if D only followed in these languages' 
footsteps, however humiliating that might feel, because it'd have 
the potential to give the language a new life. In its current 
form, its advantages over C++ seem to diminish with every new 
standard.

Whether that would happen or not, the new language would 
definitely need a solidly defined identity / value proposition so 
it'd be clear why to pick it up. It would also need a big break 
from the current design principles, which remain essentially 
unchallenged for a long time now. That might also go against some 
current mindset and eventually could be seem just too big of a 
deviation.

All in all, not sure if any of that would happen but it'd be 
really exciting!