Open bartelink opened 6 months ago
Yep I agree this is a good idea. Would you like to submit a pull request for it?
I guess arm could be twisted
Some questions though.... sequenceResultM
yields to Result<'t seq, 'err>
sequenceResultA
logically would yield Result<'t seq, 'err seq>
I find the semantics of the laziness of that hard to reason about, unless you can express it crisply? (I'm thinking it should not be lazy)
If it's not lazy, it needs to be materialized internally. If you're doing that, it's a bit daft not to just yield that given that the result is going to be :> seq<Result<_, _>
So I think the answer might be to make an Array
module with:
sequenceResultM: Result<'t, 'e> seq -> Result<'t[], 'e>
sequenceResultA: Result<'t, 'e> seq -> Result<'t[], 'e[]>
that would align with the List
module's signatures/designArguably if that was added, the Seq one could be obsoleted (unless it actually has well defined lazy semantics that is, but I doubt it)
I find the semantics of the laziness of that hard to reason abou
Yeah it seems like it's a Seq.fold, so I don't think it's going to be something that can lazily be evaluated.
Seq one could be obsoleted
Not necessarily because there are other enumerables beyond F#'s Array/List in the BCL and it's handy for those.
Updates from spiking:
Seq
module, and was going to make the sequenceResultM
return an array
on the basis that that's often useful, and it's what I intend to do for the A
variantArray
module, as realistically one would want to have most of the List
stuff in there too (but if no signature changes can be tolerated, then that's a way of sidestepping that issue). Also I am interested in having it the impl be tolerant of seq
inputs, which does not totally align with that one would expect from an Array module.one pipe forcing a newline and other such nonsense
I prefer this so this won't change.
Do signatures need to be binary compatible?
Yes unless you want to retarget for v5.
I prefer this so this won't change.
Yeah, ultimately defaults matter so not a problem (and I do get that lots of people are happy with that layout)
Yes unless you want to retarget for v5.
I can make it API compatible in the context of this PR and prepare a follow-up PR to change the contract from seq
to []
in a minimal way to be merged in the V5 timeframe
Also happy to leave the original impl exactly as it is; I have no doubt it's much closer to the idioms used in other impl pieces
~I'll assume the former~ let's discuss in the context of the PR as I'm flip-flopping, it's not time-sensitive for me, and you're the maintainer that has to deal with it all
There's a List.sequenceResultA
I'd find use for a
Seq.sequenceResultA: Result<'t, 'e> seq -> Result<'t[], 'e[]>
This would align with how Async.Parallel works (accumulate outputs in a ResizeArray, yield an array) for efficiency
Example desired consumption
Example current workaround:
(This is literally what I have, and I have limited awareness of the Validation modules etc so maybe they offer a better workaround, but it does seem that in general there's a hole in the completeness of the operations hence raising this)