-
Notifications
You must be signed in to change notification settings - Fork 20
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 List.chooseV, Seq.tryPickV, etc. for ValueOption #739
Comments
Can this one be I've no problem making an RFC for this to help get this in & documented. |
I was wondering, for the I guess if we stick to that, we should have:
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. |
@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. |
@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. |
|
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). |
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:
choose
andpick
semantics without N allocationsOption
-based usages (ofchoose
etc.) withValueOption
-based (chooseV
etc.) for likely increased performanceoption
The disadvantages of making this adjustment to F# are:
Extra information
Estimated cost (XS, S, M, L, XL, XXL): S
Related:
Affidavit (please submit!)
Please tick this by placing a cross in the box:
Please tick all that apply:
The text was updated successfully, but these errors were encountered: