Add isOk and isError to the Result type

[cmeeren]

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]

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]

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]

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

[cmeeren]

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]

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

[cmeeren]

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.

[realvictorprm]

I would need this right now for C# :(

[TheJayMann]

@realvictorprm commented

I would need this right now for C# :(

Not sure what you say you are needing for C#, whether you are wanting isOk and isError functions, or just a Result type in general. If either of those two cases, I could point you over to TheJayMann/LinqToResult which contains a Result type, which has a property named IsSuccess, and also has Linq methods which allow a syntax similar to computation expression.

If you are using the FSharp Result type directly in C#, or if you were referring to something else completely, I don't think I have any suggestions.

[realvictorprm]

Well instance members will do for now... I prefer the other variant though

[cartermp]

I'd be in favor of:

• IsOk and IsError properties on the type
• Overridden ToString method on the type
• DebugDisplay on the type
• Result module additions: inlined isOk and isError functions

[abelbraaksma]

@cartermp, 'on the type', what do you mean with that? Instance members, static members? As static members wouldn't make much sense if you also add them to the module, so I assume instance members, right?

[cartermp]

Yes, instance members.

[charlesroddie]

In addition to Result.isOk and Result.isError,

@boloutaredoubeni Should we also add ... iter, iterError ... getOk, tryGetOk, tryGetError, defaultValue, orElse?

I like getOk/OkValue and tryGetOk/toOption.

I also use ignoreOk: Result<'a,'b> -> Result<unit,'b>.

[pema99]

@charlesroddie I very much agree, but as @cmeeren said previously, these should probably be taken up in a different issue.

[gusty]

I think (part of) this feature will be automatically available once #222 is completed.

[absolutejam]

Is this still open for consideration?

I've found myself adding a lot of parallels from Option to Result(like isError/isOk) in my own projects, and I feel like it's extra value in the core without any real disadvantage.

[cartermp]

I think we'll consolidate concerns here with #222, so I'll close this out to de-duplicate