On Borrow Checking

[Timon Gehr]

On 5/10/25 06:02, Walter Bright wrote:
> On 5/7/2025 4:21 PM, Timon Gehr wrote:
>> On 5/7/25 16:47, jmh530 wrote:
>>>
>>> I can think of a few different ways forward (by no means limited to 
>>> just this)
>>
>> Well, the big issue here is that @live is still not transitive.
> 
> We are all well aware of the problems with transitive attributes. Making 
> @live transitive means that nobody will ever use it, no matter how good 
> it is. People keep asking for a non-transitive @nogc.
> ...

My point is not that `@live` should be a transitive function attribute. 
It should not be a function attribute in the first place.

For `@live` functions, not only is it a problem when they call 
non-`@live` functions, it is also a problem you call _them_ from 
non-`@live` functions.

And even then, you have not implemented checks that are even sufficient 
to guarantee anything if your entire program is `@live` with a custom 
`@live` druntime.


>> A function attribute is not really the right way to go about this 
>> anyway. Aliasing is a property of a pointer, not a function.
> 
> Attaching it to a pointer means nobody will use it, because they'll have 
> to redo their entire program.
> 

If this is really your perspective, it is better to just drop borrow 
checking as a direction. It seems your design constraints are 
self-contradictory assuming that utility is one of them. The current 
design does not incentivize people to use it, it just makes it not very 
useful.

The entire point is allowing gradual adoption with gradual benefits. 
However, this has to be done one datastructure at as time, not one 
function at a time.

In any case, what you say is simply not true, you can e.g. pass borrowed 
things as `scope` parameters, as long as you are able to control 
accesses to the owner for the duration of that function call.

But sure, if your entire `@safe` program is based around passing raw, 
non-scope pointers around, there will _never_ be a way to use these 
functions from `@safe` code using manually allocated pointers.

Note that `int*` and `scope int*` are _already_ de facto different 
pointer types (even though `scope` is implemented as an attribute).
You cannot pass a `scope int*` to an `int*` parameter. Yet for DIP1000, 
having to "redo the entire program" to use `scope` and other annotations 
was not considered a deal-breaker.

Though neither DIP1000 nor `@live` have any meaningful story about 
multiple indirections.