Proposal: EOF should be reported differently than returning 0

[polomsky]

Hello. I was reading section about handling EOF. I am new to Rust but it seems to me, that the checking if read returned 0 bytes and accept is as EOF looks similar to infamous null pointer problem. This is actually the purpose of structs like Option or Result to ensure that programmer must explicitly ignore things to make a problem.

I have read a specs of read in AsyncReadExt so I am aware of changing specs and creating BC break. I suggest to change return value from io::Result<usize> to io::Result<Option<core::num::NonZeroUsize>> or to some enum (e.g. EOF,Length). By using NonZeroUsize will get a check without paying for extra memory. I was thinking about simple Option/enum with usize but I see no real world scenario to use zero sized buffers for reading. I am aware that this is a nice feature (accepting zero sized buffers) and it seems supported by system calls but it looks to me that price for it is too high.

By this developer will be forced to handle EOF. The only disadvantage I see is that function read will have to refuse buffers of zero size and return error.

Honestly, I can not imagine situation when this would be actually useful - maybe only checking if there is a IO error without actually reading anything.

Am I missing something? I would be happy to make a PR but I don't know if would be accepted.

Thanks for answers.

[Darksonn]

Can you please open a real issue instead? The discussions tab is for receiving help with using Tokio.

[Darksonn]

Replaced by #2717.