Re:Never patterns, exhaustive matching, and uninhabited type...
by the8472 on Saturday August 18, 2018 @08:27AM
(#17788161)
When you implement a generic trait that is designed to handle errors but your specific case is infallible then it is helpful to indicate that the error case can never occur. Marking that as uninhabited makes it easier for downstream consumers to just eliminate all code related to error handling for that concrete type.
[ Parent
| on HN ]
Re:Never patterns, exhaustive matching, and uninhabited type...
by phyzome on Saturday August 18, 2018 @08:20PM
(#17791697)
An example I can think of is Java's StringReader class. It implements the Reader interface, so it has to bear the "throws IOException" signature... but it's impossible for it to produce an I/O error, since it's not actually doing any I/O, just reading from a String.
That's fine if you're using it via the Reader interface, but if you're working with StringReader directly it's a pain in the butt to deal with the non-existent exceptions. It sounds like never-patterns would help with that.
Re:Never patterns, exhaustive matching, and uninhabited type...
by zebraflask on Saturday August 18, 2018 @07:07PM
(#17791353)
Please don't flame me if this is an ignorant question, but how is uninhabited different from Javascript's undefined? That's what I would use undefined for in JS (very loosely speaking).
Re:Never patterns, exhaustive matching, and uninhabited type...
by Veedrac on Saturday August 18, 2018 @07:39PM
(#17791533)
You can actually set a variable to `undefined` in Javascript. You can't set a value to an uninhabited type─there is no value that represents the type.
Re:Never patterns, exhaustive matching, and uninhabited type...
by zebraflask on Saturday August 18, 2018 @07:41PM
(#17791541)
I get it, so the concept is closer to declaring a variable and that's it, nothing further happens.
Thanks.