[sirwhinesalot]

It is unfortunate that the title mentions borrow checking which doesn't actually have anything to do with the idea presented. "Forget RAII" would have made more sense.

This doesn't actually do any compile-time checks (it could, but it doesn't). It will do runtime checks on supported platforms by using page protection features eventually, but that's not really the goal.

The goal is actually extremely simple: make working with temporary data very easy, which is where most memory management messes happen in C.

The main difference between this and a typical arena allocator is the clearly scoped nature of it in the language. Temporary data that is local to the function is allocated in a new @pool scope. Temporary data that is returned to the caller is allocated in the parent @pool scope.

Personally I don't like the precise way this works too much because the decision of whether returned data is temporary or not should be the responsibility of the caller, not the callee. I'm guessing it is possible to set the temp allocator to point to the global allocator to work around this, but the callee will still be grabbing the parent "temp" scope which is just wrong to me.

[Sesse__]

> "Forget RAII" would have made more sense.

For memory only, which is one of the simplest kinds of resource. What about file descriptors? Graphics objects? Locks? RAII can keep track of all of those. (So does refcounting, too, but tracing GC usually not.)

[sirwhinesalot]

You deal with those the same way you deal with them in any language without RAII, some sort of try-with-resource block or defer.

Not making a value judgment if that is better or worse than RAII, just pointing out that resources of different kinds don't have to be handled by the same mechanism. This blog post is about memory management in C3. Other resource management is already handled by defer.

[Sesse__]

Why would you treat the two differently, though? What benefit does it bring? (defer is such an ugly, manual solution in general; it becomes very cumbersome once you may want to give control of the resource to anyone else.)

[sirwhinesalot]

Well, the answer is obvious in garbage collected languages: because a GC excels at managing memory but sucks at managing other resources.

Here, the answer is that ownership semantics are disliked by the language designer (doesn't fit the design goals), so they're not in the language.

[pjmlp]

Not really obvious, given that there are garbage collected languages with RAII, like D, to quote one example.

And even stuff like try/using/with can be made RAII alike, via static analysis, which defer like approaches usually can't, because it can be any expression type, unlike those other approaches that rely on specific interfaces/magic methods being present, thus can be tracked via the type system.

So it can be turned into a compiler error if such tagged type doesn't escape lexical scope without calling the respective try/using/with on the variable declaration.

[sirwhinesalot]

Not disagreeing, just pointing out the reasoning.