Thoughts on Backward Compatibility (page 3)

February 20

Re: Thoughts on Backward Compatibility

Posted by Sebastiaan Koppe
in reply to Atila Neves

Permalink

Sebastiaan Koppe

Posted in reply to Atila Neves

Permalink

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?

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.

Forums