Add List.chooseV, Seq.tryPickV, etc. for ValueOption

[cmeeren]

Add List.chooseV, Seq.tryPickV, etc. for ValueOption

I propose we add ValueOption equivalents of the following functions:

• List.choose / Seq.choose / Array.choose / Event.choose / Observable.choose
• List.pick / Seq.pick / Array.pick / Map.pick
• List.tryPick / Seq.tryPick / Array.tryPick / Map.tryPick
• List.unfold / Seq.unfold / Array.unfold

(For the sake of completeness: Additional functions in these modules that could be implemented too are all the tryX functions that only return an option, but in this suggestion, I choose to concentrate only on the above since they allocate N objects instead of 1).

The existing way of approaching this problem in F# is... none, really, apart from writing low-level implementations similar to what would go into FSharp.Core.

Pros and Cons

The advantages of making this adjustment to F# are:

• Increased performance, since we can use choose and pick semantics without N allocations
• Allows later replacing F# internal Option-based usages (of choose etc.) with ValueOption-based (chooseV etc.) for likely increased performance
• Better feature parity with option

The disadvantages of making this adjustment to F# are:

• Added function bloat (I'd say that for these N-allocating functions it's worth it)

Extra information

Estimated cost (XS, S, M, L, XL, XXL): S

Related:

• Previous discussion in dotnet/fsharp
• Implementation PR

Affidavit (please submit!)

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

[abelbraaksma]

Can this one be approved-in-principle @dsyme? An implementation (dotnet/fsharp#6781) has been ready for some time (since July last year), and I believe this would be nice to have in F# 5.0 if possible :).

I've no problem making an RFC for this to help get this in & documented.

[gusty]

I was wondering, for the try... functions, isn't the current expectation to return a ref option?

I guess if we stick to that, we should have:

• tryPick
• tryPickV
• tryVPick
• tryVPickV

I'm under the impression this claims for a solution at compiler level, like a mechanism to auto-convert/overload (with type inference defaults) between ref and struct options / tuples.

[abelbraaksma]

@gusty, I believe the idea is that the V versions use value options all through, and without the V it's the classical way of reference options.

But I agree that some type directed way would be a better solution in the long run, which would allow either type of option in any position. But that poses the problem of how to write different paths if they get auto converted.

[En3Tho]

@dsyme @KevinRansom Is there any progress on this? This (with @abelbraaksma 's fixes) would actually be useful in compiler internals. There are places where List.chooce could be easily replaced with valueChoose.

[travis-leith]

chooseV would be really useful for a numerical experiment I am working on.

[dsyme]

I'll mark this as approved in principle. However I'm aware it's a big addition and should perhaps be done outside FSharp.Core.

@vzarytovskii This may motivate shipping an additional FSharp.Collections.Extensions or something

[vzarytovskii]

I'll mark this as approved in principle. However I'm aware it's a big addition and should perhaps be done outside FSharp.Core.

@vzarytovskii This may motivate shipping an additional FSharp.Collections.Extensions or something

Yeah, @KevinRansom is exploring the possibility for us to ship FSharp.Core as multiple separate packages, this might be a good candidate to start experimenting with it (as well as the same treatment we have for F# core - implicit import, etc).

[voronoipotato]

@vzarytovskii am I gonna have to import a second thing for everything to get all the features. If so I'd prefer things to stay as they are unless it makes development easier for you.

[vzarytovskii]

@vzarytovskii am I gonna have to import a second thing for everything to get all the features. If so I'd prefer things to stay as they are unless it makes development easier for you.

No, it will be implicit for users as it is now, just will allow us structure things better, ship things more selectively, and will make it possible to shadow implementations with specific ones for target runtime.