3 ms·
A "maybe" type is logically incompatible with "subatomic I/O". When a sized-read() syscall results in a short read AND a raised error. The only sensible thing t
by ribasushi 6y ago
A "maybe" type is logically incompatible with "subatomic I/O". When a sized-read() syscall results in a short read AND a raised error. The only sensible thing to do is to return both.
I am not familiar with Rust, but looking around the docs on Read [https://doc.rust-lang.org/std/io/trait.Read.html#errors https://doc.rust-lang.org/std/io/trait.Read.html#errors] I see:
> If an error is returned then it must be guaranteed that no bytes were read.
Could someone elaborate how a system can satisfy this guarantee, seems impossible...?
- UK-Al05 6y agoYou could write sum type that handles multiple cases. Value Error ValueAndError
- learc83 6y agoThat’s hardly a reason not to include a maybe type. In that particular case, instead of a maybe you can use a combination of sum and product types or just an additional ShortRead type. NormalRead | ShortRead | Error This case is also an example of why go’s idiom of using error value or return value doesn’t always work. If you had a maybe type and a general sum type it would be clear when a function was going to return either or both.
- Measter 6y agoThat's an API choice. There's no technical reason at all why you couldn't return some kind of error AND read data if you wanted, you'd just have to make your Error type a product type.