Which arguments for deinit (or other invalidating functions)?

[Sze]

@jbe

But do I really need to know if deinit mutates the state after I decide to give up ownership, promise to not touch the struct anymore, and request cleanup?

I care about the opposite, I want to have lots of things that don’t mutate and declare that with self: T, so that I don’t have to bother about what it is doing / have to read less code to verify what it is doing.

For the compiler deinit is just another function, so you may have promised something to the programmer reading the code, but not to the compiler.

@jbe

I (naively) assumed that by passing noalias self: *T and setting self.* = undefined; at the end of the function, the compiler should have enough information to optimize the call in such a way that it may pass the argument by value or reference internally, whichever is faster.

I don’t know what the exact definiton of noalias would be in Zig (there currently isn’t documentation for it), but even without it, just because it is set to self.* = undefined at the end doesn’t mean that it being a pointer is irrelevant before that and recognizing whether it could be a value, requires analysis of all the code before that which could be many functions deep, with self: T it is immediately clear that it doesn’t matter without any analysis, you immediately know that the pointer isn’t stored away anywhere where it will later be retrieved from (and used in a useful/working way), or similar shenanigans.

I don’t really want to distinguish between invalidating functions vs other functions, instead I want to write the code in such a way that it is easy to understand and doesn’t require a bunch of different rules/logical thinking frameworks based on what kind of function it is.

And also so that the compiler doesn’t have to be too clever and analyze too much to figure out what it is allowed to do to optimize it, because the compiler should be fast, but if it has to do too much work to figure out things, it probably won’t be fast.

Basically I think const and var and its effects are useful to make it clearer to the programmer what can and can’t change.

@jbe

As cited above, my initial idea actually was that “deinitialization” or “passing ownership” is sort-of a kind of its own that might even deserve its own language construct.

Zig doesn’t deal with ownership, the programmer does.

I think if you wanted to deal with ownership and lifetimes in the language, that would quickly turn Zig into a very different language than what it currently aims at. It might be an interesting thing to explore, but I don’t think that is within what is being considered for Zig itself.

Regarding such things, you might be interested in this topic:

Vale's First Prototype for Immutable Region Borrowing

I found this interesting in itself, although I have not tried Vale myself. https://verdagon.dev/blog/first-regions-prototype

And this project:

GitHub - ityonemo/clr: Checker for Lifetimes and other Refinement types