first batch of Result changes - API completeness: * <https://github.com/status-im/nim-stew/pull/176> \- add isOkOr / isErrOr - these "complete" valueOr etc for void * <https://github.com/status-im/nim-stew/pull/177> \- <https://github.com/status-im/nim-stew/pull/28> with new names, for converting back/forth between Opt - there is some overlap here with existing functionality under other names but this brings a "regular" way to pull out the error/value from a Result and put it back there * <https://github.com/status-im/nim-stew/pull/178> \- I'm not a fan of mapConvert, mapCast but if we have them there, they should be balanced by corresponding error versions - the reason they exist is basically to work around the syntactically onerous and implementation-wise inefficient function passing facilities of Nim - these feel like special cases that on their own wouldn't motivate cluttering the API * <https://github.com/status-im/nim-stew/pull/179> \- treating Opt/Result as a collection of 0/1 items is a useful model when "growing" a data type - you start with 0 items, then 1 items, then 0/1 items then general 0/n items in increasing order of code complexity - nonetheless, functions that work with 0/n constructs obviously also cover the 0/1 case
I've had most of these lying around in my git stash in one form of another - the aim would be to ensure that the API is complete and balanced with respect to some of the ways that Result theoretically can be modelled - because these models overlap slightly, the result is that some of the API also overlaps slightly (okOr vs orErr for example) - I'm going to follow up with more documentation about these different ways of viewing Result
