Consider dropping the IO capability

[adamw]

The IO capability was originally introduced to make signatures more "truthful". It requires any methods that perform I/O directly or indirectly to include IO in scope.

However, after testing this in Bootzooka, I'm not sure it carries its weight. True, the project is small, but even there the necessity to often add using IO was more annoying, than useful. All the places where this was needed where predictable, and it's usually obvious from the method name that I/O is happening anyway.

That's why I propose to remove the feature (along with the compiler plugin) from Ox entirely. Similar functionality might be implemented by a separate project, without the integration e.g. with Ox's streams.

[adamw]

Related to: https://x.com/adamwarski/status/1836713537898430966

[adamw]

If'd you have some opinion regarding this, a 👍 / 👎 would be great - or a comment even more so :)

[lbialy]

The correct question in this regard is - what effects are actually worth tracking this way. John De Goes thinks effect tracking is worthless. Martin thinks Async is worth it. My opinion is that for practical purposes well implemented, relatively fast coroutine runtime like Loom or Golang makes it mostly obsolete as to know whether some call will suspend execution brings no value to me - for example: of course grpc call will perform side effects and "suspend" (if that means anything with something like Loom, anyway), that's why I'm performing it! The whole thing boils down to an information about "this method call might be slow(er)". But so can a call to a SAT solver! IO capability is kinda pointless without referential transparency achieved by suspending monad. There are however things that do seem to be worth tracking - resource scopes - and they do, in fact, require capture checking. I'm not sure this is what was what Martin had in mind - to have a Connection "capability" that is tracked so that it can't be mistakenly exfiltrated and used-after-close.

[adamw]

Yes, I agree about suspensions, IO was designed to track I/O only - so side-effecting operations which might fail.

We do have resource scopes which remain unchanged in how they are tracked