Finish implementing Result

[chriskrycho]

Here's the reference implementation in TypeScript.

List of things to implement: TODO

Notes

• As noted, the Ok.IsOk() and Err.IsErr() methods should be simple properties, not methods. (The reason they were methods in the TS implementation was so they could be used for "type narrowing.") I would keep the Result.IsOk() and Result.IsErr() static methods which are useful for checking them in a "functional" style.
• We probably don't need any of the aliases from the original implementation, because they are just there for ease of migration from other JS libraries.
• ap is named ap instead of apply only because apply already has a usual meaning in JS. I don't think that's the case here, so using Apply makes way more sense to me.

On curried methods

It's certainly not difficult to supply overloads of the functions for a "functional" style—but it's also not especially idiomatic in C♯ from everything I've seen, so the value proposition seems lower. If folks want it, my thought is we can add them in e.g. a 1.1 release—but I'm happy to help get them shipped if it turns out people do really want them!

[aggieben]

I think the only real case for methods here would be in a function composition scenario, and there isn't one in C♯, to my knowledge.

[chriskrycho]

Clarification: you said "for methods"; I assume you meant "for curried methods"?

[aggieben]

I didn't say any of those words 😄 . I was just unsure how these methods could be used in C♯ where properties wouldn't actually do better - although now that I've slept on it, it does occur to me that the methods would support a functional style via Linq (e.g., resultList.Where(Result.IsOk)).

As a more general proposition I don't think it's necessarily desirable to have direct ports of everything from TypeScript since the languages (and type systems in particular) are so different. In this case it seems like it would be beneficial.

[chriskrycho]

Totally concur that a direct port isn't desirable!

I do think there's a lot of value in things like you suggest there, as well as for any case where it is desirable to do a more functional style with Func etc.

[aggieben]

Going to close this in favor of #14. I suspect properties should still be part of the more explicit API, but hopefully we can go with the flow of the typesystem and mostly make them unnecessary.