On Borrow Checking

[Timon Gehr]

On 5/10/25 23:20, Walter Bright wrote:
> 1. `scope` is not part of the type.

I stated as much, but it still influences type checking, so it is 
formally part of the type system.

> It is a storage class, not a type 
> modifier. The only type modifiers are immutable, const, shared and 
> inout. Those are pervasively handled throughout the compiler's dealings 
> with types. Making a new pointer type would be a huge effort *in 
> addition* to all the other work needed to make a borrow checker.
> ...

Sure, so don't do it if you think it is not worth it. It's necessary to 
have annotations that are part of types to make meaningful progress on 
this though. Note that I am pretty sure that your issues with type 
modifiers in DMD are largely due to the way they are implemented. I 
don't think it would be very hard to add such features to my own frontend.

> 2. We have a lot of experience with transitive attributes. There's a lot 
> of resistance to using them because of this. Just look at all the 
> complaints about `nogc` being transitive.

Well, sometimes you want it to be transitive, sometimes you just want to 
avoid implicit allocations. It's different use cases and they should be 
distinct features. OpenD adopted my proposal for `pragma(explicit_gc)` 
and it helped me chase down some unwanted implicit GC allocations in my 
programs without flagging all the instances where I was deliberately 
using GC.

> Personally, I find `const` 
> being transitive as a serious impediment to using `const` in the dmd 
> source code. One of the big problems is it doesn't work with the Visitor 
> pattern. (There are a couple cases where `const` is just cast away, 
> shame on me.)
> ...

Well yes, as I have been saying for years, don't use `const` if you want 
to mutate. As you would not use features that restrict aliasing if you 
want to freely alias. There is no free lunch, if you want 
machine-checkable guarantees, you have to follow a certain discipline.

`@live` however is discipline for its own sake, without the slightest 
hint of practical machine-checkable guarantees.

> 3. I'm well aware that ideally @live would be sounder if it is 
> transitive.

No. Again, ideally there would be no `@live` function attribute in the 
first place. It's the wrong way to decide where to do type checks.

Anyway, there is sound and unsound. And there are directions to follow 
that can in principle lead to a sound design with enough effort, and 
there are directions to follow that will never lead to a sound design. 
`@live` is in the second category, `@safe` is in the first category.

> I disagree with the notion that it is useless if it is not.

I am not going to use it. It is useless to me. Not because it is not 
transitive, but because it does not even pretend to want to achieve 
anything.

> I am 98% sure that if @live was made transitive, it would be instantly 
> useless because nobody is going to be willing to make an existing 
> program or library pass the borrow checker.

It appears that you did not read what I wrote in my previous post, you 
are still attacking the same straw man that I already disowned.

You are correct here. `@live` is useless whether it is transitive or not.

> (It took enormous effort for 
> Rust to convince people they had to throw their existing code away and 
> recode it from scratch to use the borrow checker.) Much of the existing 
> code would have to be thrown out. Making a perfect borrow checker is the 
> enemy of making a practical, useful one.
> ...

Nonsense. Being practical and useful is of course part of perfection. 
Soundness is just also needed, if the utility sought is memory safety 
guarantees.

And if the goal is not memory safety guarantees, I just don't see why 
people would bother with this. What customer or boss will be like: "You 
really need to use `@live` when you code up this program for me." I 
really don't see it.

> 4. Making dip1000 transitive made it impractical to use in existing code.
> ...

No, the problem with DIP1000 you are referring to that it adds 
additional restrictions for existing syntax, so if you want to adopt it 
you have to first pay the up-front cost of updating your existing code. 
This simply does not happen if the new feature uses syntax that is not 
used in the wild.

Of course, even then you will get what you pay for in terms of 
annotation and type checking overhead, but with `@live` you get way less 
than what you pay.

Anyway, hardness of adoption is simply the nature of DIP1000, as its 
goal was to fix holes in @safe without making certain use cases 
impossible in @safe code outright. I suspect with editions, people will 
be able to adopt DIP1000 (or its more expressive future successor) 
incrementally, which will make it significantly more practical.

> 5. dip1000 makes it an error to assign a scope pointer to multiple 
> indirections (because scope isn't a type modifier).
> ...

Sure. Code often has multiple indirections in practice though.

> 6. When an @live function calls another function, a `scope` parameter is 
> a borrow, and a non-scope parameter is an ownership transfer.
> ...

Well, operationally it acts somewhat like these. Semantically this is 
not what happens.

As I have stated in the past, it's a bit like cargo cults in the 
pacific. Operationally, you have people that act kind of like staff 
maintaining a landing strip. In practice, no planes actually are landing 
or taking off from there.

`@live` signs contracts for borrowing and/or sale with much fanfare and 
will sometimes stop you from doing what you want to do, but no lending 
takes place and no ownership is actually transferred.

> 7. Compiling an @live function is slow because of the DFA. Making it 
> transitive would make it apply to the whole program, which would then 
> compile as slow as Rust.
> 

Not true, you only have to enhance type checking where the features are 
actually used. This is not a `@live`-specific thing at all.