Thoughts on Backward Compatibility

[Sebastiaan Koppe]

On Tuesday, 20 February 2024 at 09:03:15 UTC, Atila Neves wrote:
>
> In the case of DIP1000 specifically I think maybe Robert's idea 
> of moving its checks to `@trusted` may be that way forward, and 
> making `@safe` regular GC D. Once I'm done with editions I'm 
> going to write a DIP for this.

For me dip1000 isn't about the GC though, but rather about 
avoiding the use of an object after it has been deconstructed. In 
its simplest form this involves restricting usage of a pointer.

The reason I would want to restrict it is because I know the 
thing it points to to be dead at some point in my program and I 
want the compiler to ensure any usage doesn't violate that. 
(Which incidentally is why I believe any allocator needs to 
return essentially a scope pointer).

It is a way to have objects with deterministic lifetimes and the 
guarantee of correct usage by restricting it to some scope.

Importantly, this goes beyond just memory. Just because I use the 
GC and no longer have to care about the lifetime of raw memory, 
doesnt mean I stop caring about lifetime of objects in general.

Plenty of resources need deterministic destruction. Modelling 
them as non-copyable structs is an excellent way to achieve that 
_and_ avoid reference counters. After which its natural to use 
dip1000 to pass them around.

Even if you put them on the heap you would want to ensure there 
is no usage after they are logically freed.

Buffers are a good example. They typically live on the heap, you 
will want to reuse them to avoid churn, and you will want to 
ensure downstream code doesn't accidentally escape them. So you 
make them scope and rely on dip1000.

Now all that has to be @trusted?