i think you are missing that a proper io interface should encapsulate all abstractions that care about asynchrony and patterns thereof. is that possible? we will find out. It's not unreasonable to be skeptical but can you come up with a concrete example?
> As a library author, how do I handle an io object that doesn't behave as I expect
you ship with tests against the four or five default patterns in the stdlib and if anyone wants to do anything substantially crazier to the point that it doesnt work, thats on them, they can submit a PR and you can curbstomp it if you want.
> function coloring
i recommend reading the function coloring article. there are five criteria that describe what make up the function coloring problem, it's not just that there are "more than one class of function calling conventions"
An interface is a library decision, not a language decision. The level of abstraction possible is part of a language decision. GP is saying that this adds "too much" possible abstraction, and therefore qualifies as "too high level". Another benchmark about "too high level" would be that it requires precisely the "guess the internal plumbing" tests that you describe.
Not really advocating anything, just connecting the two a little better.
yes indeed true. but the standard library is in the end just a library, you could reimplement the "pre-io" patterns in the new std if you wanted.