On Sunday, 25 September 2022 at 17:04:51 UTC, Sebastiaan Koppe wrote:

That's a necessary condition for being able to deallocate memory in @safe code, period. You can only do it if it doesn't create any dangling pointers.

Not necessarily. The proof is allowed to rely on runtime information, like reference counts, which the compiler does not necessarily know about. In these cases, the programmer can cast the pointer to isolated in @trusted code (similar to how you can cast away shared in @trusted code after locking a mutex).

On Sunday, 25 September 2022 at 12:03:08 UTC, Paul Backus wrote:

It makes sense to me, though I'm not an expert. Another way to think about it is some way to incorporate ownership into the type system.

Walter hasn't been convinced yet that @live isn't sufficient. I think this would need to be proven to his satisfaction before he starts considering alternative. Maybe it can't hurt to flesh this argument out further?

Nevertheless, I think being able to do allocator-aware @safe reference counting should be a necessary condition before moving to @safe by default.

On Sunday, 25 September 2022 at 12:03:08 UTC, Paul Backus wrote:

Couldn't it be @safe iff the particular allocator's deallocate is @safe (or missing)?

On Friday, 14 April 2023 at 13:42:15 UTC, Atila Neves wrote:

Yes. The obvious follow-up question is, "what does it take to make a deallocate method @safe?" And the answer is: it takes isolated, or some other way to restrict aliasing in @safe code.

As Timon [1] and others [2][3] has helpfully explained, now that we have @system variables from DIP 1035, it is possible to do this without adding new language features, although the UX is not ideal.

So, the current next step on the TODO list is to design a new allocator API that takes advantage of these techniques to make deallocate @safe.

[1] https://forum.dlang.org/post/tr9j1h$1fvd$1@digitalmars.com
[2] https://forum.dlang.org/post/xggosoodlcegitocruwf@forum.dlang.org
[3] https://forum.dlang.org/post/gdkikaklqyvxdyklvmug@forum.dlang.org

On Friday, 14 April 2023 at 13:42:15 UTC, Atila Neves wrote:

An interesting question. In principle, you COULD make @safe allocator that allocates out of a static memory block. You are only getting and returning void[] slices, which in itself isn't @system. What makes it dangerous is that those void slices are them used as storage for arbitrary types. So if your @safe allocator doesn't do what it's supposed to you can end up overwriting live pointers, because the allocation machinery does @trusted casts that rely on the custom allocator behaving right.

In practice it's probably going to be a problem. Maybe the allocator should instead return some wrapper type over void[] that can only be created or destructed in @system code.