Figure out how to handle SI-2712 fix

[ceedubs]

The infamous SI-2712 is fixed under the "experimental" compiler flag in scala 2.12. The fix is available via a compiler plugin for scala 2.10 and 2.11. We should figure out how cats is going to handle this change. Should it remove Unapply and ask people to use one of these two approaches if they want an SI-2712 workaround? Keeping around other SI-2712 workarounds such as Unapply could potentially cause issues with this fix in place.

cc @milessabin

[kailuowang]

If the SI2712 fix is required on the use site, would that mean that all libraries they use must be also at least SI 2712 fix compatible (i.e. hide their unapply properly) ?

[ceedubs]

If the SI2712 fix is required on the use site, would that mean that all libraries they use must be also at least SI 2712 fix compatible (i.e. hide their unapply properly) ?

I'm hoping @milessabin can weigh in, as he probably has a better idea on when problems can arise. At work we added the SI-2712 fix plugin to a project that uses scalaz heavily, and we were able to change a bunch of traverseU calls into just traverse and didn't seem to have any issues. I'm guessing that potential issues come up if you call code that uses something like Unapply (instead of changing traverseU calls to traverse), resulting in now-ambiguous instances.

[milessabin]

The plugin would be required downstream for 2.10.x and 2.11.x. The fix can be backported (basically already has been), and we might be able to persuade Lightbend to make a 2.10.7 and 2.11.9 release with it included.

[kailuowang]

BTW, if nobody has reported yet, I tested cats with SI-2712 fix plugin and some tests failed to compile due to ambiguous instance. Maybe the first step should be fixing those?

[non]

Here's my 2¢:

I think the easiest thing is to leave the unapply machinery in, and not use the SI-2712 fix in Cats, but to try to ensure that everything we provide can be used with the option/plugin by downstream libraries and end users. Until there are early adopter reports for the fix I think it's likely that there will be other people who are nervous about it, so I'd like to support them in the short term (but not necessarily the long term).

Also right now library authors who want to support cross versioning will have to do a fairly tricky SBT set up to conditionally enable compiler plugins or flags depending on the Scala version. This is definitely possible, but it's harder than I'd like. I think a big first step toward standardizing on this fix would be creating an SBT plugin that papers over the version distinction (i.e. it knows if a given version requires a plugin or a -Y option), allowing library authors to cross-build and publish easily.

Once we reach a place where either the fix is available in all versions we care about (2.10 through 2.12 currently), or we have an SBT plugin that figures it out for us, I'm much more open to tearing out the unapply machinery and having everyone standardize on the SI-2712 fix.

[kailuowang]

conniptions @djspiewak generally use to "just give me partial unification" from 2.10 through to 2.12
https:/djspiewak/base.g8/blob/master/src/main/g8/build.sbt#L81-L88 and
https:/djspiewak/base.g8/blob/master/src/main/g8/build.sbt#L96-L102

[tpolecat]

My vote is to remove Unapply for cats 1.0 … the 2712 fix is well known at this point and available for all versions. I don't think it's worth the effort to maintain the machinery any longer (much less until 2.0).

[mpilquist]

👍 for removing for 1.0.

[kailuowang]

It looks like that the consensus is to tear out the Unapply machinery and having everyone standardize on the SI-2712 fix. I am going to work on a PR.