Is it time for D 3.0?

Francesco Mecca me at francescomecca.eu
Sun Mar 29 13:35:35 UTC 2020


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

What about phobos and the druntime then?
If we switch to D3 it makes sense to shrink the druntime to a 
smaller one that doesn't bring all the weight of unused features.

I don't know the rust model and I only have experiences with 
python libraries working with both py2 and py3.
What about keeping D2 and D3 code interoperable between each 
other? That would mean offering the possibility to use a D2 
library in a D3 codebase and a D3 library in a D2 codebase, in 
the same way we do with C right now.


More information about the Digitalmars-d mailing list