After many iterations and bug-fixes, we (Status) are finally moving to Nim 1.6 (where previously 1.2 was used for stability reasons) - in light of this, I've started thinking about reviewing [`Result`](https://github.com/arnetheduck/nim-result/) from the point of view of efficiency, ergonomics and API making it the best `Result` type it can possibly be given where the language is at - the review would be aimed at:
* safely start introducing 1.6 features like lent (Zahary has a proposal here for example: <https://github.com/status-im/nim-stew/pull/88>) - this would mean that we keep supporting 1.2, but selectively start using 1.6 features as well where applicable (so 1.6 feature set may deviate from 1.2) * clean up / review API for inconsistencies around `Opt`/void etc - `valueOr` vs `get`, `template` vs `func` etc (`Result` via the `Opt` alias works more or less as a complete `Option` replacement with the difference that it allows `some(nil)` values) * see if there's anything that can / should be removed - ie features that receive little use (`Exception` integration for example) * review the options for `await` and `?` again and see if we can settle on one * consider what language improvements would make sense to make `Result` more ergonomic Because of the "core vocabulary" status, I deliberately want `Result` to move slow - that said, this review would be a good opportunity for presenting any radical ideas as well - I do not promise they will be included, but I do promise to consider them seriously while trying to balance all the competing tradeoffs for the library itself :) Once the review is done, it might also make sense to publish / tag 1.0 - thoughts on the value of this welcome (ie would it help or hinder usage of Result).
