Drop -Y flags that change language semantics

[adriaanm]

removes:

• -Yno-adapted-args
• -Xstrict-inference
• -Xfull-lubs
• -Yoverride-objects
• -Yoverride-vars
• -Yinfer-argument-types
• -Yvirtpatmat

See scala/scala-dev#430

This is the first cut. Open for discussion.

[adriaanm]

The last commit failed, largely because of check file changes: https://scala-ci.typesafe.com/job/scala-2.13.x-validate-main/741/testReport/ (it's sooooo nice to have a page like this to link to!)

My understanding is that we should put the FINAL bit back on objects, since its removal was a half-finished change to support the -Yoverride-objects flag.

[eed3si9n]

Kind of sad to see this one go. I only learned about it recently, but I thought it was a good cop.

[adriaanm]

This PR is part provocation to hear any passionate defenses of the defendants :-)

[milessabin]

I'm quite happy to see that one go. As Scala sharp edges go it's one of the least harmful (you're unlikely to silently miscompile because of it) and most useful (see various bits of arity-polymorphic sugar in shapeless and thereabouts).

[eed3si9n]

Here's an easy example of things compiling:

scala> case class W[A](elem: A)(implicit ordering: Ordering[A])
defined class W

scala> W(1, 2, 3, 4)
res0: W[(Int, Int, Int, Int)] = W((1,2,3,4))

And to quote @lrytz in scala/bug#8342:

Auto-tupling is not mentioned at all in the spec.

Here's another voice from the wild:

To which @tpolecat responds "-Yno-adapted-args."

I am not so much for or against the removal of -Yno-adapted-args per se, but I'd request a more principled solution toward this general problem. Adaptations.scala is already riddled with flags (settings.future, settings.noAdaptedArgs, settings.warnAdaptedArgs).

option 1

Here's a proposal. Remove zero-arg eta expansion in 2.13 (or under -Xsource:2.14), and also remove auto-tupling under -Xsource:2.14 if Dotty can go along with it.

[adriaanm]

Here's a proposal. Remove zero-arg eta expansion in 2.13

Yup: #6475

remove auto-tupling

Would be nice...

[adriaanm]

In any case, our guiding principle is alignment with Dotty, so, looks like we can at least deprecate auto-tupling in most cases in 2.13 (drop it in 2.14), and implement the same approach as dotty by 2.14.

[joroKr21]

Dotty still has the regular auto tupling which I don't care much about. But the function parameter tupling is something different that doesn't exist in scalac and I find it quite useful.

[adriaanm]

Ah, thanks for the correction. Wasn't aware they still had auto-tupling :-( I would really like to drop that, while I agree the one for function literals seems useful.

[eed3si9n]

In an effort for reconciliation, I've opened a thread here https://contributors.scala-lang.org/t/lets-drop-auto-tupling/1799, please comment and subscribe.

[milessabin]

@eed3si9n sure, you can construct examples of that sort. It's a lot harder to find examples where that's a problem in actual practice. They exist, but they're rare.

[puffnfresh]

-Yno-adapted-args is very important to the projects I work on in Atlassian.

-Xfuture also changes semantics (e.g. the withFilter fallback) in a very useful way. Will it also be removed?

[adriaanm]

I'm not for auto-tupling (see above), but I'm against flags that fragment the language. They cause confusion, reduce test coverage, complicate code,... The intent is to keep only -Xsource, to have the compiler do its best to emulate one version in the past or future (which subsumes -Xfuture).

I'd like to understand both your use cases better so we can see about supporting them by default. If we can convince the dotty folks to drop auto-tupling, I'd be happy to deprecate in 2.13 and remove in 2.14. withFilter is already the only supported method for desugaring if in a for in 2.12 -- the fallback to filter has been removed (#5252).

[adriaanm]

I've dropped the commit about restoring the acc_final flag for nested objects and rebased (will create a ticket). Would like to consider merging this for M4. (See scala/scala-dev#497)

[dwijnand]

Does it makes sense, for now, to retain the auto-tupling flag, given there's at least some interest by Martin in dropping it in Scala 3?

[adriaanm]

Once we figure out the deprecation story, we'll make it (the deprecation path) available under -Xsource and -deprecation.

[SethTisue]

for the record, I'm confident -Xstrict-inference can go, I did due diligence on it over at #6593 before Adriaan pointed out it the removal is included here already.

[adriaanm]

I note your hesitation on auto-tupling, @dwijnand. I'd like for us to accept slight regressions in the process of cleaning this up. I've logged this as scala/scala-dev#496.

[som-snytt]

Now all my PRs with new -Y options have merge conflicts.

I only just noticed that the letter Y represents a fork and is really the best symbol for options that change semantics.

Similarly, -X should be reserved for chiasmus options that invert the meaning of your code.

[SethTisue]

I'm (still) confused why -Yno-adapted-args got the axe. I've opened a separate ticket on it; let's discuss there: scala/bug#11110