Anonymous
11/9/2025, 1:21:29 PM
No.107152233
>>107146206
>no? at some point you populated that structure with the allocator so you should be aware that it is there + you still have to handle allocation errors
Just because you are aware does not mean it's still explicit.
>and where did that struct come from?
For example from code you have not written. When using or writing a library for example.
>and instead called something else that called init - then you must have passed the allocator to that preceding function, and so on, recursively until the call that you did write and took an allocator parameter
This is only true if you are writing the final binary, not if you are just writing some library that others will use.
And still. Even if you were the one to write it all your code. The mere fact that some structure include allocators means that any of their function can cause allocations and you just can't know without checking the code or docs. And even if that information is in docs, that function might be called by another function, and another function and so on, and which each layer it is less and less likely that their documentation and code will have any information about some allocations deep in nested function calls. That would make it a leaky abstraction and pain in the ass to refactor because you have to manually propagate all that information through docs. And of course, if you instead never wrote any managed structures and passed allocator as argument to virtually any function that might happen to call some function that allocates somewhere deep nested in the call stack, the result will be the same. As you build more layers of abstraction, such low level detail as allocation will be smudged and every function will seem to might cause allocations in some cases under some state and when every function might allocate or might just pass it somewhere else then all this explicitness goes out of window.
>no? at some point you populated that structure with the allocator so you should be aware that it is there + you still have to handle allocation errors
Just because you are aware does not mean it's still explicit.
>and where did that struct come from?
For example from code you have not written. When using or writing a library for example.
>and instead called something else that called init - then you must have passed the allocator to that preceding function, and so on, recursively until the call that you did write and took an allocator parameter
This is only true if you are writing the final binary, not if you are just writing some library that others will use.
And still. Even if you were the one to write it all your code. The mere fact that some structure include allocators means that any of their function can cause allocations and you just can't know without checking the code or docs. And even if that information is in docs, that function might be called by another function, and another function and so on, and which each layer it is less and less likely that their documentation and code will have any information about some allocations deep in nested function calls. That would make it a leaky abstraction and pain in the ass to refactor because you have to manually propagate all that information through docs. And of course, if you instead never wrote any managed structures and passed allocator as argument to virtually any function that might happen to call some function that allocates somewhere deep nested in the call stack, the result will be the same. As you build more layers of abstraction, such low level detail as allocation will be smudged and every function will seem to might cause allocations in some cases under some state and when every function might allocate or might just pass it somewhere else then all this explicitness goes out of window.