>>107144222
>by making this distinction you are proving my point
No. I claimed that Rust and C++ let you work in environments with no global allocator.
You responded by talking about how zig does it.
I have shown you that Rust also does it in that way.

>and you can't be sure a rust function won't use-after-free
You actually can for any correct(sound) code.
This is irrelevant to the topic at hand.
We were talking about how Zig allocations are not always explicit. Use-after-free is irrelevant to allocations being explicit or not.
Stop trying to change the topic.

>>107144222
>I assume you mean the managed version and the append function. you are passing an allocator:
>if you used the managed (deprecated) version you wouldn't need to pass it the allocator as an additional parameter
If they changed it they should update the documentations because that's not what is written on the zig.guide and any example I find when I search for this function.
And the point still stands. If this was allowed before then it will be allowed afterwards. At some point your structure will be "managed" and then all that explicitness goes away. Otherwise, you are going to add an extra allocator argument to 90% of your functions and once again you won't know when allocations happen. You already don't really know if std.ArrayList.append will allocate or not, it might or it might not. This uncertainty only amplifies the further you move allocator along the call stack.

>>107144234
>>107144284
pic related