Alphabetically it would be allocator.
But I guess we will see how the ecosystem at large will do it.
Is it more likely to have functions that need an allocator but no io, or functions that need an io but no allocator? If the first, I would use (allocator, io, ...); if the second, the other way around.
2 Likes
largely depends on what the program/library is, I think an overall likelihood is quite arbitrary, as is this issue of parameter order.
1 Like
Sure, but for example @bitcast used with another builtin (I donāt remember which one) have an order which is defined by zig fmt, a similar thing would be nice for allocator and io IMO
Lolā¦ I guess we are just gonna need to divide ourselves into two different tribesā¦
#TeamAllocatorFirst and #TeamIoFirst.
1 Like
I agree,
all the āergonomicsā aside, there is one technical reason i can see why it should be one way, over the other.
In Zig the first argument of a function is āspecialā, it allows the function to be called like a method, which leads me to the question:
What is more likely?
That IO interface method might be accepting an Allocator parameter, or that Allocator interface method might be accepting IO parameter?
I think that the first is more likely, so i am for IO first.
(but it could be the case that they just dont refference each other and then it does not matter, we will have ot see how the IO interface will look like in the end for that)
Robert 
My interpretation was the conversation was from the perspective of calling the function, you are talking from the perspective of writing the function.
I think the latter perspective makes this conversation more meaningless than it already is, as a type that has data is always going to put itself first in its functions, so callers can use zigs syntax sugar for calling methods, interfaces are no exception.
That common practice makes the methods on the interfaces in question exceptions to this conversation.
2 Likes
This conversation is somewhat āmeaninglessā already. Its just style guide question, so i dont think your point stands. Also its worth to mention that you cant use the syntax sugar for methods every time.
My point was, since there is the only one technical argument for one over the other.
(as far as i can see)
Why just not make all occurances of IO and Allocator accepting functions the same, especially when there is no reason not to?
āinserting the () from my previous msg hereā
Robert
If we make the wild assumption that before 1.0 lands, there may be another similar common dependency that gets added
(I canāt for the life of me think what that might look like, but you never know)
In which case, passing the 1st param as a ādependenciesā struct that can grow as needed might not be a totally dumb idea
Ugly but infinitely future proof
1 Like
I canāt fathom where the motivation for such a suggestion comes from. Functions are good, parameters are good. Adding a parameter when you need it is good. Deleting a parameter when you donāt need it is good. This is the basics of programming
3 Likes
Suggestion was half in jest, but it solves the daunting question of which param between allocator vs io gets 1st place at least.
Jokes aside, it would be good to set that policy early to make all function signatures use a consistent ordering when both dependencies are needed
Bike shedding on steroids
Regarding the parameter ordering, my 2 cents are, stop worrying, stop bike shedding.
3 Likes
it doesnāt even do that because you have to decide which one goes first in the struct
That would be left to the user since struct fields can be assigned in any order, no? Which is different from function parameters that require the ordering dictated by the function author.
Honestly, if more ubiquitous interfaces like this are added, it seems likely that some will start using this pattern regardless of it being discouraged.
Not that it really matters (nor am I necessarily advocating for it). Just a thought.
3 Likes
Haha yea. So are you #TeamAllocatorFirst or #TeamIoFirst? Choose wisely since a lot of people will follow this 
.
Thereās a lot of actually interesting things to talk about here. How about letās choose those topics rather than this inane non-issue?
- restricted function pointers
- the future of recursion
- the ābring your own OSā use case
- upgrade/migration strategies and release timing
- memory allocation/management of coro stacks
- collaboration on other Io implementations (kqueue, Windows IOCP)
- comparison with prior art
- brainstorming ideas of how to make special testing Io implementations to catch bugs
3 Likes
Just trying to have a little bit of fun on the forum with other fellow developers given all the other craziness happening in the world. Of course this is a superficial conversation, but I will keep that in mind for future posts.
1 Like
sorry for being a buzzkill! I guess I got jaded by all the bafflingly ignorant commentary on HN
1 Like
No worries :).
What about āCan I get Allocator from IOā ?