search

haskell / core-libraries-committee

95 stars 16 forks source link

Restrict the type of `Data.List.NonEmpty.unzip` #86

Closed mixphix closed 1 year ago

mixphix commented 2 years ago

Currently we have unzip :: Functor f => f (a, b) -> (f a, f b) exported from Data.List.NonEmpty. The implementation can remain the same, but I propose that the type should be restricted to unzip :: NonEmpty (a, b) -> (NonEmpty a, NonEmpty b) for analogy with Data.List as well as to avoid exporting overgeneralized functions from specific modules. Really, why should we be exporting something that works with any Functor from Data.List.NonEmpty?

Bodigrim commented 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?

mixphix commented 1 year ago

+1

Bodigrim commented 1 year ago

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?

mixphix commented 1 year ago

Raised: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/10189

Kleidukos commented 1 year ago

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)

mixphix commented 1 year ago

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.

ndmitchell commented 1 year ago

@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")