Feature requests: convenience helpers and improved spec compliance

[aaronhuggins]

Some features that I'd like to contribute from my personal implementation that this one is missing. Opening issue for discussion before just opening a pull request to help eliminate unnecessary work. Some of these are convenience, some of these bring the implementations closer to the Rust spec. Porting these is little effort, as the code already exists in my own personal work.

Convenience helpers

• function fromPromise<V, E extends Error>(promise: Promise<V>): Promise<Result<V, E>>; avoids additional microtasks
• function fromSync<V, E extends Error>(func: () => V): Result<V, E>; synchronous helper, avoids microtasks completely
• Symbol.toStringTag support; useful to quickly and easily distinguish resulting objects
• Symbol.hasInstance support on Err, Ok, Some, None; example myResult instance of Err

Spec compliance

• Iterable support, similar to class Result<T, E extends Error> implements Iterable<T>
• Result.expectErr

[OliverBrotchie]

Hey man, thanks for opening an issue I really appreciate the interest! Here are my thoughts:

Convenience helpers

• I definitely agree about separating out synchronous and asynchronous froms. I think the best naming convention for this would be to have from as the sync method and fromPromise as the async method.
• Symbol.toStringTag, could you give an example of how this might be used?
• Symbol.hasInstance, 100% that's a good shout.

Spec Compliance

• Iterable support, what would an implementation of this look like?
• Result.expectErr, again this is definitely a good inclusion.

[aaronhuggins]

Thanks for getting back to me! I appreciate the positive response and feedback, that's cool.

Convenience helpers

• Hard agree on this point; one reason I had for suggesting an alternate naming conventions is that an async from already exists and I was concerned with breaking changes. If braking changes are okay, I think this is a welcome adjustment to the API.
• Symbol.toStringTag is used by JS engines when calling Object.toString calls; would produce [object Err] for example instead of [object Object], which is useful during debugging and with runtime checks some folks use.
• Symbol.hasInstance cool.

Spec Compliance

• Iterable support allows easy access to the value if any; a for...of would have either a single iteration or no iteration, and Array.from could be used. It's a type of transposition pattern in Rust which I find useful. Could be either an implicit implements Iterable<T> which would be JS "native" or an iter method like Rust
• Result.expectErr, nice.

[OliverBrotchie]

@aaronhuggins I have opened a PR with all of the above changes except Symbol.hasInstance.

What did you have in mind for this? Converting Ok, Err and Some to symbols?

[aaronhuggins]

Oh! I was literally planning on opening the PR and contributing my existing code. 😆

I'll get you my code samples or get you another PR if you want.

[OliverBrotchie]

Oh sorry! 😆

Yeah if you could provide some snippets that would be great!

[aaronhuggins]

I'll add as comments in PR.