You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Looking at the implementation, I have a feeling that the generalized unzip may have negative performance implications, and that's why it wasn't generalized in Prelude:
--| The 'unzip' function is the inverse of the 'zip' function.unzip::Functorf=>f (a,b) -> (fa, fb)
unzip xs = (fst<$> xs, snd<$> xs)
Before making this change in rio, I'd like to hear why it wasn't included as part of FTP. If it's just an oversight, then I'm OK with the change.
As a counterpoint, the specialized version is also exported from Data.List (and RIO.List) so it remains available. Granted, this doesn't negate the concern about a surprising performance cost -- even if we document it, how many people are going to check the docs before using unzip?
Odd thing I just discovered: the default
Prelude
andRIO.Prelude
both have...but Data.List.NonEmpty provides
This feels like it just got left behind during FTP, are there any arguments against generalizing it?
The text was updated successfully, but these errors were encountered: