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

Add isOk and isError to the Result type #623

Open
cmeeren opened this Issue Nov 22, 2017 · 6 comments

Comments

Projects
None yet
2 participants
@cmeeren

cmeeren commented Nov 22, 2017

I propose adding isOk and isError to the Result type/module, similar to how we have isSome and isNone in the Option module.

Currently one has to define the functions manually:

[<RequireQualifiedAccess>]
module Result =

  let isOk = function
    | Ok _ -> true
    | Error _ -> false

  let isError = not isOk

Pros and Cons

Advantages:

  • It brings the Result type more in line with the Option type
  • It saves a few lines when you just need to check if something is Ok or Error (similar to checking if an Option is Some or None)
  • There's really only one right way to do this, so it might as well be part of the standard library

Disadvantages: None.

Extra information

Estimated cost: XS

Affidavit

Please tick this by placing a cross in the box:

  • This is not a question (e.g. like one you might ask on stackoverflow) and I have searched stackoverflow for discussions of this issue
  • I have searched both open and closed suggestions on this site and believe this is not a duplicate
  • This is not something which has obviously "already been decided" in previous versions of F#. If you're questioning a fundamental design decision that has obviously already been taken (e.g. "Make F# untyped") then please don't submit it.

Please tick all that apply:

  • This is not a breaking change to the F# language design
  • I or my company would be willing to help implement and/or test this
@boloutaredoubeni

This comment has been minimized.

Show comment
Hide comment
@boloutaredoubeni

boloutaredoubeni Mar 6, 2018

Should we also add other types to the Result module, such as iter, iterError and accessors for Result.Ok and Result.Error, like getOk, tryGetOk, tryGetError, defaultValue, orElse?

boloutaredoubeni commented Mar 6, 2018

Should we also add other types to the Result module, such as iter, iterError and accessors for Result.Ok and Result.Error, like getOk, tryGetOk, tryGetError, defaultValue, orElse?

@cmeeren

This comment has been minimized.

Show comment
Hide comment
@cmeeren

cmeeren Mar 6, 2018

I sometimes use iter, so I'd like that.

I'm a bit more unsure about the rest, though. With tryGet... I'm assuming you convert Result to Option, and I fail to see what benefit that brings. defaultValue is a bit different than Option.defaultValue since you are actually ignoring an error value instead of just supplying a default missing value. Not sure what you mean by orElse.

In any case, this might belong in a separate suggestion.

cmeeren commented Mar 6, 2018

I sometimes use iter, so I'd like that.

I'm a bit more unsure about the rest, though. With tryGet... I'm assuming you convert Result to Option, and I fail to see what benefit that brings. defaultValue is a bit different than Option.defaultValue since you are actually ignoring an error value instead of just supplying a default missing value. Not sure what you mean by orElse.

In any case, this might belong in a separate suggestion.

@boloutaredoubeni

This comment has been minimized.

Show comment
Hide comment
@boloutaredoubeni

boloutaredoubeni Mar 6, 2018

I was referring to val Option.orElse: ifNone:'T option -> option:'T option -> 'T option. But I can create another suggestion

boloutaredoubeni commented Mar 6, 2018

I was referring to val Option.orElse: ifNone:'T option -> option:'T option -> 'T option. But I can create another suggestion

@cmeeren

This comment has been minimized.

Show comment
Hide comment
@cmeeren

cmeeren Mar 6, 2018

Ah. I can see the use, but as with defaultValue, you're actually ignoring an error value, and one might want to make that explicit.

cmeeren commented Mar 6, 2018

Ah. I can see the use, but as with defaultValue, you're actually ignoring an error value, and one might want to make that explicit.

@boloutaredoubeni

This comment has been minimized.

Show comment
Hide comment
@boloutaredoubeni

boloutaredoubeni Mar 6, 2018

Well it can be seen as a way to "recover" from an error

boloutaredoubeni commented Mar 6, 2018

Well it can be seen as a way to "recover" from an error

@cmeeren

This comment has been minimized.

Show comment
Hide comment
@cmeeren

cmeeren Mar 6, 2018

Yes, that makes sense too. In any case, there are considerations there that are not relevant for isOk and isError, so I suggest detailing that in a different suggestion.

cmeeren commented Mar 6, 2018

Yes, that makes sense too. In any case, there are considerations there that are not relevant for isOk and isError, so I suggest detailing that in a different suggestion.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment