Thoughts on Backward Compatibility

[Dukc]

On Friday, 16 February 2024 at 16:15:30 UTC, Paul Backus wrote:
> 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.

For code still in active development, sure. No point in enabling 
`@safe` in the first place if there's no willingness to use it 
with the rules that are actually safe, which means turning 
DIP1000 on. If people refuse keeping structs/arrays they refer to 
at safe code in the heap and also refuse taking their time to 
learn DIP1000, then they essentially don't want real memory 
safety.

But for code in maintenance-only mode, it's different. Whatever 
bugs it may have had because of lack of DIP1000 are usually 
already caught the hard way, or if they remain they manifest only 
very rarely. That people maintaining code like that don't want to 
update it doesn't really mean they don't want `@safe` or DIP1000, 
as in this case the work-to-benefit ratio is much worse than for 
new code.

>
> 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.

Fortunately we don't have to make a hard yes-or-no decision on 
that one since the language as-is allows keeping `@system` on for 
everything.