ollie

@Noah-Kennedy See #169

@Noah-Kennedy Sure, lets keep things abstract to start with, although #165 is a concrete example. First lets consider differed work _only_, not linking SQE's Implementing this is quite straightforward. At...

@FrankReh I'm less concerned about matching io_uring, and more concerned that our futures violate the published behaviour of Futures. As I've at least partially demonstrated, it doesn't _hurt_ performance

@Noah-Kennedy I think with a bit of reinterpretation, your and my approaches actually have a lot in common

My approach is rather 3 states, not 2 `Builder` -> `Deferred` -> `In flight` The way I'm approaching Builder in the first instance is for use the Op struct as...

likewise, I'll get my stuff I'm up. I'd be very suprised if eitehr approach is rigth first time out. Lets get our Pr's up, and take some time to review....

I, as usual, have gone the other way. I was thinking that if I had a builder, linking to the next op is a logical way of consuming a builder

The best stated argument for the status quo is from @mzabaluev , which i quote > I agree that this API is not intuitive, but this is what we have...

Its interesting that it goes down the concrete type with destructor rather than trait object route. Presumably on code generation efficiency grounds.

We could shift entirely from the `IoBuf` and `IoBufMut` traits to [owned-buf](https://github.com/nrc/owned-buf/blob/main/src/lib.rs). ~It could also replace `FixedBuf`~. The `OwnedSlice` and `OwnedCursor` variants in that library would also replace our slicing...