Add return type restrictions to I/O methods#10580
Add return type restrictions to I/O methods#10580straight-shoota merged 2 commits intocrystal-lang:masterfrom
Conversation
|
|
||
| # Always raises `IO::Error` because this is a read-only `IO`. | ||
| def unbuffered_write(slice : Bytes) | ||
| def unbuffered_write(slice : Bytes) : NoReturn |
There was a problem hiding this comment.
I'm not sure about this. The abstract method def has no return type (it should probably be Nil, but that's breaking), so I'd probably not add one here, either. Even if it never returns.
Ditto for similar methods. This is up for debate, though.
There was a problem hiding this comment.
Well I wouldn't edit the abstract method, of course. And I certainly noticed that this is controversial too. In the end, though, I don't see why not add this. It is directly documented right above that Compress::Deflate::Reader#unbuffered_write will never return. We're not saying anything about base classes.
There is a more general decision to make about return types. For example, the vast majority of <=> methods return Int32, even though other values are possible in some cases. And in the same way, I don't see why those methods shouldn't be documented as such. Due to Hyrum's Law (especially well applicable due to the way that Crystal works), people are already using those values as exactly Int32, so it's better to specify it explicitly so that accidental breaking changes are noticed at least.
|
This is not approved BTW |
|
Can we revert this one? It introduced a breaking change because some shards (or maybe the std?) is returning Int64 instead of Int32 for the unbuffered_read method. |
3 participants
No description provided.