Move the Cartesian parameter for mapN et al?

[davegurnell]

A proposal for the mapN syntax.

The Cartesian parameter for the mapN syntax and its cohorts is injected in the implicit conversion to TupleNCartesianOps:

https://github.com/typelevel/cats/blob/master/project/Boilerplate.scala#L265

This means that, if the compiler can't find a Cartesian for your type, it gives the error "the method mapN doesn't exist". I ran into this when updating some code using mapN on Validated because I didn't have -Ypartial-unification enabled.

If the implicit parameter was injected in the parameters to mapN instead, the error would change to "can't find a Cartesian for your type". I think is clearer and more indicactive of what's going wrong.

Does this seem like a good tweak or would it break things? Sorry if this ground has been covered already.

[edmundnoble]

This is how most of the syntax in cats works; the more that works this way, the better IMO (#1669)

[kailuowang]

looks like the consensus is to make the change. anyone interested in drafting a PR?

[davegurnell]

I'll have a go in the next few hours. [EDIT]: Actually, I don't think I'll be able to do this. Firing up SBT gives me loads of dependency resolution errors. I think they're related to SBT 0.13.16. Looking into these issues is going to take me down a rabbit hole that I can't afford right now. Sorry. I'll post again later if I can free up time. In the mean time, this one is up for grabs.

[DavidGregory084]

I'll have a look at this since it's my fault ;)