Is it time for D 3.0?

Dukc ajieskola at gmail.com
Tue Mar 31 23:08:26 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.

I don't think heavy-handed breaking of backwards compatibility is 
worth it. Even if we were to do it, redesigning the standard 
library should be enough - no need to break the compiler.

>
> Some issues I can think of:
>
> 1. The safe by default debate
Isn't it quite simple? Just add a way to apply `@safe:` and 
`@system:` on the top of module without them applying to template 
inference, and it really does not matter what the default will be.

> 2. pure by default
> 3. nothrow by default
Same as above, except they obviously will need antiattributes 
that turn them off

> 4. String interpolation DIP
Should hardly be a breaking change

> 5. auto-decoding
This is the only thing of these that I think would make the 
transition worthwhile, were there many more issues of this 
caliber. But even this is only about Phobos, not the language 
spec.

> 6. range.save
Each range should just decide their behaviour on copy. Since 
forgetting to `.save` is so common, changing copy behaviour of a 
public range will break code anyway, so the behaviour can be 
guaranteed just as well.

> 7. virtual by default
Small issue after all. Can be further mitigated by adding 
`virtual` keyword so one can add `final:` on top and cancel it 
where applicable.

> 8. ProtoObject
No opinions on this - haven't followed.


That all being said, I would welcome a way to better deal with 
code breakage, so the breakage could be more aggressive. For 
example, if one could compile together both modules that rely on 
autodecoding Phobos and modules that rely on non-decoding Phobos, 
issue fixed.





More information about the Digitalmars-d mailing list