Change the way transmit buffer lengths are populated?

[robomancer-or]

So I'm implementing phy::TxToken for my board, and it seems really weird to me that the signature is:

fn consume<R, F>(self, timestamp: Instant, len: usize, f: F) -> Result<R>
    where F: FnOnce(&mut [u8]) -> `Result<R>;

What this suggests is that the number of bytes populated by the call f(&mut buf) is known before f is called... which strikes me as wacky. Is there some reason the signature isn't

fn consume<R, F>(self, timestamp: Instant, f: F) -> Result<R>
    where F: FnOnce(&mut [u8]) -> `Result<(usize, R)>;

where f returns the number of bytes actually populated?

Would you be open to a PR that makes this change?

[whitequark]

Yes. With the signature you suggest, how large the buffer you pass to f is going to be?

[robomancer-or]

Ah, I see, I forget that some people can use dynamic memory. So it's up to the caller to request exactly as many bytes as their packet is going to end up being... that still seems odd. What about

fn consume<R, F>(self, timestamp: Instant, capacity: usize, f: F) -> Result<R>
    where F: FnOnce(&mut [u8]) -> `Result<(usize, R)>;

where the understanding is that the one returned from the closure is the one that represents the number of bytes to transmit.

[whitequark]

What's the point of this change exactly? smoltcp is specifically designed to know the exact number of bytes it's going to transmit upfront.

[robomancer-or]

Oh. I didn't realize that. Sorry, the documentation on docs.rs is pretty out of date, so I'm trying to work out how to use it all by reading the source, I missed that tidbit. Forget I said anything :-)

[whitequark]

Ah, sorry for that, I should make a release soon.