Thoughts on Backward Compatibility

[Dukc]

On Friday, 16 February 2024 at 01:44:51 UTC, Paul Backus wrote:
> To everyone else reading this, I'd like to leave you with one 
> last question: what do **you** like about D? What strengths 
> does D have, as a language, that you'd like to see become even 
> stronger?

You managed to have me look DIP1000 in a new light. If it's going 
to be made the default, the choices are:

1. Put in a lot of thought to make the code compile.
2. Move stack-allocated stuff to the heap so there's no need to 
fight with `scope`.
3. Mark the code where there are problems `@system`.

As you said, 1. can be a real problem. If the code has been 
already battle-tested, it's far too much effort to be worth it if 
the code in question will not go any major overhauls anymore. 2. 
is okay in most cases - fortunately - but it can't be a general 
answer, especially not for a systems language like D.

And we really don't want people doing option 3. It's less of a 
problem than combining `@system` and stack references for new 
code, but the code is still probably going to see some changes. 
`scope` is an incredible footgun outside `@safe`.

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.