Ryan Summers

> The top-level application changes look more frightening, but that's primarily because what would be the executor is rolled into there. This is my original concern - if we convert...

It seems to me that the approach of implementing a "dummy" executor has the trade-off of forcing overhead boilerplate onto non-async applications, but gives them the ability to use `async`...

> > non-async applications > > Are they even a thing any more with embedded-nal, now that the blocking modes have been removed in 0.2? Non-async embedded applications make up...

> From how I understand the available example, users already use a dummy executor, they just always roll own (here in the form of sleeping-for-some-milliseconds, and I'm not convinced that...

I worry that any attempt at forcing buffering in the `embedded-nal` layer would preclude zero-copy implementations mentioned in https://github.com/rust-embedded-community/embedded-nal/issues/12, which I believe would be quite useful. If we could make...

I believe this is primarily stuck because async cannot be done on stable `no-std` Rust currently - I believe GATs are currently blocking most implementations. See https://github.com/rust-embedded/embedded-hal/pull/285 After talking with...

It would also be desirable to have a `write` equivalent of this. These types of functions allow us to create zero-copy abstractions for higher level protocols, such that we can...

The main complication I see is that not all network stacks will support zero-copy abstractions. Take for example a TCP stack using the W5500 ("hardware" network stack that communicates with...

> I don't necessarily think we need to force anyone to implement it. I think if we propose it into the trait, that's essentailly what we have to do. >...

I've added a sample for a TCP stack in https://github.com/ryan-summers/embedded-nal/blob/feature/closure-read-writes/src/lib.rs#L29-L106 The main downside of a default implementation is that we need to break a `read()` into distinct actions: 1. Acquire...