2.13.1 regression, using higher kinds without language-level import no longer emits a compiler warning

[oxbowlakes]

In 2.13.0:

Welcome to Scala 2.13.0 (OpenJDK 64-Bit Server VM, Java 1.8.0_181).
Type in expressions for evaluation. Or try :help.

scala> def foo[M[_]]: Unit = ()
               ^
       warning: higher-kinded type should be enabled
       by making the implicit value scala.language.higherKinds visible.
       This can be achieved by adding the import clause 'import scala.language.higherKinds'
       or by setting the compiler option -language:higherKinds.
       See the Scaladoc for value scala.language.higherKinds for a discussion
       why the feature should be explicitly enabled.
foo: [M[_]]=> Unit

But in 2.13.1

Welcome to Scala 2.13.1 (OpenJDK 64-Bit Server VM, Java 1.8.0_181).
Type in expressions for evaluation. Or try :help.

scala> def foo[M[_]]: Unit
     |  = ()
foo: [M[_]]=> Unit

This doesn't sound too bad, but if you do have the import:

import scala.language.higherKinds

And you also use the compiler flags -Xfatal-warnings -Ywarn-unused then your code will no longer compile!

[oxbowlakes]

I've been pointed to scala/scala#8348 and that higherKinds is now deprecated (I didn't notice this in the release notes).

When these decisions are made (I see that Seth indicated it was discussed & agreed at a team meeting), are people aware of the potential downstream ramifications (i.e. build failures)?

[som-snytt]

I'd recommend leaving this open for all the ergonomic issues mentioned in the linked ticket.

• warn on import of deprecated element
• don't warn about an import that has already triggered a warning (usual by-position shadowing?)
• warn on deprecated -language construct, that should be free if modeled as an import

If I haven't mentioned it already, whenever I pass Oxbow Ct I think of oxbowlakes.

[SethTisue]

are people aware of the potential downstream ramifications (i.e. build failures)

yes. build failures are good, any time we can catch something at compile-time, that's a win. it tells you something changed.

-Xfatal-warnings is especially productive in this regard, and that's a good thing. that's why it exists and that's why you chose to enable it in your build.

It may help to remember that Scala versioning is epoch.major.minor, not major.minor.patch. Behavior changes are normal in minor versions and we often make (and release-note) them.

@som-snytt feel free to open or more new tickets on the ergonomic improvements you mention

[som-snytt]

aka -Werror...

I remember it does warn on deprecated compiler options.

[oxbowlakes]

It may help to remember that Scala versioning is epoch.major.minor, not major.minor.patch. Behavior changes are normal in minor versions and we often make (and release-note) them.

Understood. It's just that it is frustrating as an end-user to include a latest version which includes fixes for what you consider to be critical bugs, to find that this also contains other changes which break your builds.

Could it be a consideration that certain minor versions are intended to only contain patches, and others to only contain improvements (odd/even perhaps)? Or is this simply too complicated?

[SethTisue]

Could it be a consideration that certain minor versions are intended to only contain patches, and others to only contain improvements (odd/even perhaps)? Or is this simply too complicated?

It's a sensible suggestion.

To some extent something like this already happens somewhat. We did consciously postpone a number of PRs to 2.13.2 because they weren't bugfixes. 2.12.10 was a bugfix release because of regressions in 2.12.9. and 2.12.8 was a bug fix release because of regressions in 2.12.7. So an alternation like you're suggesting sometimes emerges, though not a strict one.

I don't recall a scheme like this ever being proposed and discussed before. If such a discussion happened, I suspect we might end up rejecting it on the grounds that our small team can't afford the additional ceremony. But I'm not sure.

[Jasper-M]

It may help to remember that Scala versioning is epoch.major.minor, not major.minor.patch. Behavior changes are normal in minor versions and we often make (and release-note) them.

Though from a binary compatibility perspective it's epoch.major.patch.