Thoughts on Backward Compatibility

[Paul Backus]

On Friday, 16 February 2024 at 15:20:34 UTC, Dukc wrote:
> Before, I would have said that if the code doesn't compile with 
> DIP1000 it isn't verifiable as safe anyway, so nothing to be 
> done. In practice though, even pre-DIP1000 safety checks are 
> usually much better than `@system` or `@trusted`, and 
> *especially* better than non-`@safe` code _with scope 
> references_.
>
> I didn't think much of the language foundations decision to 
> keep pre-DIP1000 semantics the default until we have editions, 
> but considering this it starts to make sense. We need a way to 
> selectively enable pre-DIP1000 semantics for old functions 
> before we move on, otherwise the choices for those who have old 
> code are just too stark.

I think for DIP1000 to succeed, we're going to have to come at 
this from both directions. Yes, we need to do as much as we can 
to reduce the burden of adoption, but even if we do, DIP1000 is 
always going to be a high-impact breaking change. Which means 
that *in addition to providing a migration path*, we need to have 
strong buy-in from the community that `@safe` is one of D's core 
strengths, and improvements to `@safe` are something they're 
willing to suffer some breakage for.

If we don't have that buy-in, then, as much as it pains me to say 
it, the correct move is probably to give up on `@safe` 
altogether, and focus our efforts on improving D's other 
strengths.