0.16.0 bikeshed: io before alloc, alloc before io, not an issue?

[WeeBull]

@glfmn

By Haskell convention, arguments get sorted from least changing to most changing so it would unequivocally be fn(*Io,*Allocator) since you have 1 Io in the whole application.

I realise this is already something that’s been discussed elsewhere, but I’m going to say it anyway. If io only has one value for the whole application, why is it a run-time argument being placed on every call-stack? Feels like a prime use-case of a comptime argument.

[pachde]

Because it isn’t always a single instance per program. There can be multiple Ios, just like multiple Allocators.

[jmctagger]

I feel like Trinity is telling us we’ve been down that road before….

@WeeBull

If io only has one value for the whole application

I think it’s easy to imagine an application that uses one Io for disk tasks and a different one for network tasks.

@WeeBull

being placed on every call-stack

I also think it’s still valuable, in light of clarity/transparency, for each function to indicate whether it does allocations and/or io. If the pattern is followed properly, then if I’m calling a foo, and it has no io arg, then no io is going to happen, even 200 calls down the call stack. That’s useful top-level knowledge for a low-level language.

[WeeBull]

@jmctagger

I also think it’s still valuable, in light of clarity/transparency, for each function to indicate whether it does allocations and/or io.

Oh, I have no problem with that. Having the code document that it performs IO operations is fine. Having the CPU place a constant on every IO related function call stack is unnecessary work. Small in the global view of things, but something that could be optimised away.