Closed mixphix closed 1 year ago
@hasufell making NonEmpty
functions less gratuitously lazy is tracked in #107. IMO it would be strange to change laziness of one function only, but leave everything else as is, as it would introduce even more accidental inconsistency.
@mixphix could you please cast your vote on https://github.com/haskell/core-libraries-committee/issues/86#issuecomment-1480224739?
+1
Thanks all, we have enough votes for the proposal to pass.
@mixphix would you like to execute on Step 1 of https://github.com/haskell/core-libraries-committee/issues/86#issuecomment-1480224739 and raise an MR?
Hi from the cabal team! Do y'all know if there is a retrie
or hlint
rule that can be distributed over communication channels? Perhaps something as simple as replacing unzip
with (fmap fst &&& fmap snd)
I'm no expert but something along the lines of
- warn: {name: "Avoid NonEmpty.unzip", lhs: "Data.List.NonEmpty.unzip", rhs: "(fmap fst &&& fmap snd)"}
(or Data.Functor.unzip
, depending on your preference) may work. I'm not sure how hlint
handles qualified names like that.
@mixphix - that works. Given the user already made the choice to use a function for this, and that &&&
isn't all that common, I'd suggest the Data.Functor.unzip
variant. Happy to take a patch adding that to HLint, probably with a note explaining and that points at this issue (add , note = "Because the function is being deprecated"
)
Currently we have
unzip :: Functor f => f (a, b) -> (f a, f b)
exported fromData.List.NonEmpty
. The implementation can remain the same, but I propose that the type should be restricted tounzip :: NonEmpty (a, b) -> (NonEmpty a, NonEmpty b)
for analogy withData.List
as well as to avoid exporting overgeneralized functions from specific modules. Really, why should we be exporting something that works with anyFunctor
fromData.List.NonEmpty
?