Add NotGiven compatibility module

[bpholt]

Scala 3 introduced scala.util.NotGiven: a special class used to implement negation in implicit search.

While techniques existed to implement this functionality in some cases in Scala 2, the NotGiven trait was not backported to Scala 2. This makes cross-compilation more frustrating than it needs to be, so this module was created to make a single org.typelevel.scalaccompat.scala.util.NotGiven available to Scala 2.12, 2.13, and 3.

This is based on prior work by Shapeless and fs2.

This was initially proposed as typelevel/tsc#171, but I agree that this repo is a better home for this code.

[bpholt]

I used Jetbrains Junie in IntelliJ to add some motivating examples / tests that don't compile on Scala 2 without the new module. Hopefully that's helpful.

I'm not sure we needed to wait for that, but now that it's there, I think this is ready to be reviewed @satorg @armanbilge.

[satorg]

@bpholt , thank you for the PR! It looks great overall, but I'd vote for naming consistency here.
The existing sub-project name is annotations and its published module name is scalac-compat-annotations.

For the new module I'd personally prefer to have something like notgiven and scalac-compat-notgiven correspondingly – just to keep the naming consistent across the project.

Moreover, for now we only get NotGiven here, but I can imagine that in the future we may want to provide cross-compiling compatibilites for other Scala3 features. How about renaming the new module into features/scalac-compat-features or utils/scalac-compat-utils? (utils – because NotGiven is in scala.util package, but features would be even more generic).

[bpholt]

@bpholt , thank you for the PR! It looks great overall, but I'd vote for naming consistency here. The existing sub-project name is annotations and its published module name is scalac-compat-annotations.

For the new module I'd personally prefer to have something like notgiven and scalac-compat-notgiven correspondingly – just to keep the naming consistent across the project.

Moreover, for now we only get NotGiven here, but I can imagine that in the future we may want to provide cross-compiling compatibilites for other Scala3 features. How about renaming the new module into features/scalac-compat-features or utils/scalac-compat-utils? (utils – because NotGiven is in scala.util package, but features would be even more generic).

Makes sense! I updated this in a05e47e.

[satorg]

@bpholt ,
you can simply
import org.typelevel.scalaccompat.annotation.unused
And then use that unused in NotGivenSuite.

It is defined in this repository and provided by sbt-typelevel automatically. So no need for "scala-collection-compat" whatsoever.

[satorg]

I guess the reason for this package name is to avoid sharing the package between NotGiven implementation and its tests, correct?

Since it is about tests only, we could simply name package tests and put the file into feature/src/test/scala/tests directory – it would be short and clear, I think. Or package other, if you like it better.

[satorg]

Just to clarify: it isn't really important, but when I open the project in IntelliJ IDEA, it complains that package other.org.typelevel.scalaccompat.scala.util doesn't correspond to the directory path. Of course, it doesn't affect the build itself, but I don't see a reason why we have to introduce such a discrepancy. We could move the tests into ".../other/org/typelevel/scalaccompat/scala/util" directory, but for the tests it doesn't have to be that long either – a short "tests" or "other" or whatever will do the job, I guess.