cmeeren commented 5 years ago

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

Please tick this by placing a cross in the box:

[x] This is not a question (e.g. like one you might ask on stackoverflow) and I have searched stackoverflow for discussions of this issue
[x] I have searched both open and closed suggestions on this site and believe this is not a duplicate
[x] 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:

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

abelbraaksma commented 4 years ago

Can this one be approved-in-principle @dsyme? An implementation (https://github.com/dotnet/fsharp/pull/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 commented 4 years ago

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 commented 4 years ago

@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 commented 3 years ago

@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 commented 3 years ago

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

dsyme commented 1 year ago

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 commented 1 year ago

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 commented 3 months ago

@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 commented 3 months ago

@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.

vzarytovskii commented 3 months ago

Example: if project is targeting ns2.0 and implicitly using FSharp.Core-netstandard2.0, it will be same as now. If project will be targeting net10.0, it will load base FSharp.Core (probably netstandard2.0/netstandard2.1) and one more dll, which will be (for example) FSharp.Core.net10, which may use features from newer BCL.

voronoipotato commented 3 months ago

Ah wonderful, this sounds great then :). I recently ran into this actually where it would have been particularly nice to have a valueoption unfold. Part of why I commented on it :P.

fsharp / fslang-suggestions