[hawski]

Yes, but it still is a part of the standard library and how the standard library does things - a convention. Same as in C, as malloc is just a function. You could create a replacement library for C stdlib and it could also expect an allocator in the parameters if a given function could allocate.

[coldtea]

>Yes, but it still is a part of the standard library and how the standard library does things - a convention. Same as in C, as malloc is just a function.

Yes, but it doesn't argue that it's not the same in C. Just that it's not the same as languages who do the memory allocation themselves.

>You could create a replacement library for C stdlib and it could also expect an allocator in the parameters if a given function could allocate.

You could do anyting in C, even write Zig in it. And vice versa, you co do malloc in Zig. But allocators are how Zig is designed/used, whereas C opts for malloc.

[cztomsik]

You could, but it's not idiomatic in C. Zig is basically built around this.

[hawski]

Their standard libraries are built around the notion, but I would argue that putting allocation in their respective stdlibs instead of a part of the language makes it possible to be flexible if needed. There are non-trivial and semi-popular C programs that do not use the C stdlib at all.

I agree that the culture is different and that is significant, but I do not see it in the notion of the language itself (without its stdlib).

Also what is idiomatic for Zig does change as it is not a mature language. Though the allocator passing is expected to remain. Odin did an interesting thing and the allocator is put in a 'context' which is an actual part of the language.

[unwind]

It would be hard for a replacement with the purpose of modernizing a way of working to be idiomatic at the same time. It would be an explicit attempt to update what is idiomatic, and of course not be the same as what was before.

It's actually a rather interesting idea, if I had the time for a C-focused side project that sounds really fun! :)