New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adds some documentation/examples #51
Conversation
e9751cb
to
1dfd545
Compare
Without allocating a list in between
60f7458
to
a64b822
Compare
Co-authored-by: Joachim Breitner <mail@joachim-breitner.de>
src/Result.mo
Outdated
/// Motoko does not have exceptions, so we use a datatype to encode these | ||
/// outcomes. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/// Motoko does not have exceptions, so we use a datatype to encode these | |
/// outcomes. | |
/// Motoko does not have exceptions, so we use a datatype to encode these | |
/// outcomes. | |
/// Motoko's exception handling is limited to `async` contexts. | |
/// For other contexts, Motoko provides a variant type to encode exceptional results. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead of making that rather confusing statement, maybe just delete the reference to exceptions, and justify the existence of Result
otherwise?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree we shouldn't be bringing exceptions into this, maybe we should say something about error handling in general.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Allright, I basically copied https://doc.rust-lang.org/std/result/ because I thought the description was on point.
Co-authored-by: Claudio Russo <claudio@dfinity.org>
Thanks for all the comments and review, I'll merge this and if we think the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have some minor copyediting nits that you can ignore if you wish.
LGTM.
/// | ||
/// Iterators are inherently stateful. Calling `next` "consumes" a value from | ||
/// the Iterator that cannot be put back, so keep that in mind when sharing | ||
/// iterators between consumers. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
so keep that in mind when sharing iterators between consumers.
I'm more confused than helped by this warning.
Are you effectively saying that "an iterator is a mutable object; when shared, multiple users calling next
will interfere"?
/// the Iterator that cannot be put back, so keep that in mind when sharing | ||
/// iterators between consumers. | ||
/// | ||
/// An iterater `i` can be iterated over using |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
passive voice. I prefer active voice, when possible. For instance: "A for
loop expression consumes an iterator by using its body to consume each item produced by the iterator. The variable x
(bound in the for
body) ranges over these items. "
Currently making a pass over some of the modules until I run out of steam...