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?