Make NonEmptyList covariant

[edmundnoble]

In which NonEmptyList and ValidationNel are made covariant.

[codecov-io]

Current coverage is 92.40% (diff: 100%)

Merging #1424 into master will not change coverage

@@             master      #1424   diff @@
==========================================
  Files           246        246          
  Lines          3739       3739          
  Methods        3618       3617     -1   
  Messages          0          0          
  Branches        121        122     +1   
==========================================
  Hits           3455       3455          
  Misses          284        284          
  Partials          0          0          

Powered by Codecov. Last update 468e753...a38a588

[johnynek]

I'm +1 on this. I don't really buy the variance anxiety.

That said, you can always do .widen[T] to use Functor to get it to the type you want, which should cast, which should basically be free.

I think the cats position on variance is something that deserves a doc. I actually enjoy variance, but that seems to not be a popular opinion. I know subtyping in general is not widely admired due to how it complicates type inference, but I don't know of the concrete problems we have with covariance on data types, and I'd like to see them.

[edmundnoble]

I believe attaching variance to data types and not typeclasses is the current cats position; the thing is, variance composes much more easily than functors. Once you get more than one level deep, Functor[F].compose(Functor[G]).widen(t) starts to get much worse than just t.

[ceedubs]

I'm pretty late to the show, but 👍 from me. I think that this makes it consistent with data types like Validated. It sounds like we have 👍 from @johnynek, but since variance is a touchy subject I'd maybe like to get an opinion from at least one other person. @typelevel/cats what do you think?

[ceedubs]

Also, if we merge this, I think that we should do the same for NonEmptyVector.

[johnynek]

@non what do you say? I'm still +1 on data types having variance.

…

On Fri, Jan 6, 2017 at 06:01 Cody Allen ***@***.***> wrote: Also, if we merge this, I think that we should do the same for NonEmptyVector. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1424 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAEJdiSYj66NFPX1Slfo1SMf5xd-5ULaks5rPmU8gaJpZM4KfkAk> .

[non]

I'm 👍 on this. I think a position of variance on data types is fine, but not type classes sounds like something that could work and would be consistent.

If there are concrete problems folks can point to with variance on data types then I'm open to revisiting this position.

[johnynek]

Note, I think we will need to merge master here since there may have been some methods added to NonEmptyList since this was created.

…

On Fri, Jan 6, 2017 at 07:06 Erik Osheim ***@***.***> wrote: I'm 👍 on this. I think a position of *variance on data types is fine, but not type classes* sounds like something that could work and would be consistent. If there are concrete problems folks can point to with variance on data types then I'm open to revisiting this position. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1424 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAEJdsQOnI3D3cy6P-SwzJAxge9Cufraks5rPnSrgaJpZM4KfkAk> .

[edmundnoble]

Rebased, with NonEmptyVector added to the party.

[johnynek]

👍

[kailuowang]

👍

[ceedubs]

👍 thanks, @edmundnoble!