Thoughts on Backward Compatibility

[Richard (Rikki) Andrew Cattermole]

On 21/02/2024 10:42 AM, Sebastiaan Koppe wrote:
> 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?

Agreed.

Not having reference counting in the language which overrides scope is 
bad enough and will kill scope for me in the future.

But this, this is would be the end of scope on non-delegates for me 
right now.

Users of libraries should not be touching @trusted if everything is 
working correctly.

I want @safe code protected, not @trusted.