Hacker News

points by sethops1 1 day ago | 0 comments

It sounds like you're reinventing destructors with extra steps.

They're orthogonal concepts. Zig hasn't done this, but you could absolutely combine injected allocators and automatic destructors in the same language if you wanted.

The bigger design point is who's responsible for knowing where the object lives. Zig has a balance of power more in favour of the caller than the callee, a point I tend to agree with since it's quite easy for a caller to know exactly what they want done and quite hard for a callee to know what all possible callers might want done. That principle is applied pretty liberally through the rest of the language.

[–] xedrac 1 day ago

With some notable exceptions, I would argue that most of the time, the caller simply doesn't care. Maybe the "right" approach is to provide two functions, one that takes an allocator, and one that does not. That way the caller doesn't have to care unless it wants to.

[–] hansvm 1 day ago

I see, we can solve the problem of excess verbosity by duplicating our API surface ;)

Jokes aside, that's not the worst idea (you often see the stdlib do something in a similar vein with managed vs unmanaged data structures), but I bet it doesn't survive contact with real-world programmers well enough to actually provide the portability that normal Zig code has. For transitive "style" impositions, it only takes a low rate of non-compliance for the perceived benefit to disappear.

If that's a goal you have (and IME most code is lightning fast to write, with all the heavy lifting going to impedence mismatches like the one being described, so I tend to be happy to write a bit of extra boilerplate (I like Zig, but it's an absurdly verbose language) if it means the hairier integration points will go more smoothly, and I therefore do have that goal) then the allocator API empirically works, the other solutions I've seen work much less, and I'd want to have a pretty good idea of why a contender would sate my needs instead.

If that's not a goal you have, you do you man. I can shovel out sealed Scala classes or unmaintainable numpy with the best of them as the situation demands. Nobody's created "the best" language yet. We're just casually discussing tradeoffs.