Add `Data.Functor.unzip`

[ocharles]

Currently Data.List.NonEmpty defines:

-- | The 'unzip' function is the inverse of the 'zip' function.
unzip :: Functor f => f (a,b) -> (f a, f b)
unzip xs = (fst <$> xs, snd <$> xs)

But this is a very strange place for such a generally useful function.

I'd like to propose that Data.Functor gains this function. I don't feel strongly on whether it should be a new definition, nor what should happen with Data.List.NonEmpty.unzip, only that after this proposal I can do:

import Data.Functor (unzip)

[Bodigrim]

Dear CLC members, let's vote on the proposal to add Data.Functor.unzip as per https://gitlab.haskell.org/ghc/ghc/-/merge_requests/9434/diffs:

unzip :: Functor f => f (a,b) -> (f a, f b)
unzip xs = (fst <$> xs, snd <$> xs)` 

The same function already exists in base as Data.List.NonEmpty.unzip, but it's a very strange place for something polymorphic by Functor. Cf. #86, which aims to restrict the type of existing Data.List.NonEmpty.unzip to non-empty lists only. This proposal however does not introduce any breakage per se and is a purely additive change. @mixphix @chessai @cgibbard @emilypi @tomjaguarpaw

---

+1 from me.

[mixphix]

+1

[tomjaguarpaw]

-1

---

This doesn't really seem useful enough to me to warrant inclusion in base. I also think it's not at all what you want in many cases, IO (a, b) -> (IO a, IO b) for example. I prefer holding off until we work out a Traversable variant.

[emilypi]

+1

[cgibbard]

This is a bit of a tough call because it's sort of universal, but I think I'm with @tomjaguarpaw on this one. In practical settings, it feels like there are more cases where this is something that would be a bad idea to use than there are ones where it would be desirable (a trap for type tetris players), and even when it would be the right thing semantically, it's often going to perform worse than might be possible for a given type. -1

[Ericson2314]

If this ends up being a rejection, I think the one in Data.List.NonEmpty should be deprecated too. If this doesn't deserve to exist then that also doesn't deserve to exist.

[treeowl]

If this ends up being a rejection, I think the one in Data.List.NonEmpty should be deprecated too. If this doesn't deserve to exist then that also doesn't deserve to exist.

The one currently there should be replaced with one specific to NonEmpty with the right semantics. Please go over to #107 and join the discussion.

[emilypi]

it's sort of universal

It's tough cuz of the dilemma posed in Ed's comment. Imo I'd rather see good abstractions that apply to everyone go in base, with the proper announcement for people to write their own versions than to leave them unwritten. We can track those implementations through the CLC process, and lead the way. However, I agree as a sort of soft +1 that this also poses a burden.

[Bodigrim]

@chessai could you please cast your vote?

[chessai]

it's sort of universal

It's tough cuz of the dilemma posed in Ed's comment. Imo I'd rather see good abstractions that apply to everyone go in base, with the proper announcement for people to write their own versions than to leave them unwritten. We can track those implementations through the CLC process, and lead the way. However, I agree as a sort of soft +1 that this also poses a burden.

This is how I feel - I'm also a soft +1.

[Bodigrim]

I'm not sure how soft +1 is different from just +1 for the purposes of voting :)

I'll wait for another week, just in case someone wishes to clarify/change their vote, but as it stands there are 4 votes in favour and 2 votes against.

[ocharles]

@Bodigrim has enough time passed now?

[Bodigrim]

@ocharles sorry, thanks for reminder.

With 4 votes in favor the proposal has been approved.

[ocharles]

Thanks for your input, everyone!

[chshersh]

I'm trying to summarise the state of this proposal as part of my volunteering effort to track the progress of all approved CLC proposals.

Field	Value
Authors	@ocharles
Status	merged
base version	4.19.0.0
Merge Request (MR)	https://gitlab.haskell.org/ghc/ghc/-/merge_requests/9434/diffs
Blocked by	nothing
CHANGELOG entry	present
Migration guide	not needed

Please, let me know if you find any mistakes 🙂