Thoughts on Backward Compatibility

[Sebastiaan Koppe]

On Friday, 16 February 2024 at 16:15:30 UTC, Paul Backus wrote:
> I think for DIP1000 to succeed...

For me, dip1000 has already succeeded. It aligns very well with 
structured concurrency. I use it heavily to move almost every 
async state to the stack.

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

Most of the code out there that isn't @safe is effectively 
@trusted. There is no shame in marking it as such. That generally 
provides a good transition path.

Yes, it won't get any benefits until code is @safe, but it can be 
done gradually.

There are some pain points of course, sometimes it is difficult 
to convince the compiler what the code does is safe, or when you 
have to decipher which of the many attributes one has to use. 
There is also sometimes a cascading need to sprinkle scope on 
member functions.

Generally though, I find that code that has adopted dip1000 to 
have a better api and less surprises on the inside. Its subtle, 
but is there.

So yeah, it can sometimes be very difficult to get everything 
@safe. That said, application code mostly doesn't have to care. 
Let all the tricky dip1000 concepts be constrained to libraries 
and just write applications using the GC.