| |
|
Paul Backus
| On Monday, 23 January 2023 at 16:59:16 UTC, Richard (Rikki) Andrew Cattermole wrote:
> On 24/01/2023 5:39 AM, Paul Backus wrote:
>> Have you seen the borrow method [1] used by SafeRefCounted? It is already possible, in the current D language, to prevent a container or smart pointer from leaking references. The syntax is awkward, because you have to use a callback, but it can be done.
>
> Yes I'm aware of this method. I've talked about it with Robert Schadek during last DConf Online who argued that this is the only way forward. This is not the way forward as far as I'm concerned. It is a major step backwards in usability as it is not how people work with arrays or data types in general.
I agree that it's bad UX, but what's the alternative? Implement a borrow checker in D? It'll take 5-10 years and won't even work properly when it's done. At that point, you may as well just tell people to switch to Rust.
>> Lifetime issues are not the blocker here. The blocker is being able to give deallocate/free a safe interface, so that it can be used safely in a generic or polymorphic context, where the specific implementation is not known in advance.
>
> I can't agree with that. We need to move people away from calling into allocators directly! They are an advanced concept, that is easy to get wrong especially when creating them. Which is what composing them like std.experimental.allocators does.
>
> Ultimately, I think its ok for allocators to not be @safe, they are simply too easy to get wrong without any way to prevent this at the compiler level. You use them when you want to do something more advanced without any hand holding. Use data structures like a vector type to make it @safe instead, which is why I think lifetime is the only thing blocking it atm.
I am not advocating for typical D users to call into allocators directly. The people who benefit from allocators having a @safe interface are authors of generic container and smart pointer libraries.
It is currently *impossible* to write a @safe vector type that accepts a user-supplied allocator. You can only do it if you hard-code a dependency on a specific allocator (or a specific predefined set of allocators) whose behavior you know in advance.
If your argument is that we should do exactly that, and simply give up on supporting user-supplied allocators entirely, then I can accept that as a reasonable position. Certainly it would be the quickest and easiest way to un-block progress on containers, and we can always revisit the issue in the future if necessary.
|