reconsider removal of -Yno-adapted-args in 2.13

[SethTisue]

I'm confused why -Yno-adapted-args got the axe (in scala/scala#6505, under the umbrella of
scala/scala-dev#430)

might this have been overzealous? -Yno-adapted-args is both widely used and useful IMO

and it only causes "language fragmentation" in the sense that it makes some code — code that has been producing compiler warnings since Scala 2.11 (EDIT: under -Xlint, that is, not by default) — give a hard error instead of a warning

if we were to get rid of argument adaptation entirely, as I expect to happen in Scala 2.14 and/or Scala 3, then it will make sense to remove the flag at that time. but I don't see that it makes sense to remove now

[Jasper-M]

and it only causes "language fragmentation" in the sense that it makes some code — code that has been producing compiler warnings since Scala 2.11 — give a hard error instead of a warning

There doesn't seem to be a warning without the flag, though.

[hrhino]

You need to use -Ywarn-adapted-args for the warning, which apparently made the cut, so that and -Xfatal-warnings have a similar effect in conjunction.

That said, I always turn on -Yno-adapted-args in my project, and I'll be sad to see it go. (Isn't there talk of removing it completely in Dotty?)

[dwijnand]

Duplicate of scala/scala-dev#496, I'd say.

[SethTisue]

(Isn't there talk of removing it completely in Dotty?)

yes, this "feature" is on its slow way out of existence.

You need to use -Ywarn-adapted-args for the warning

ah, right, thanks for the correction. note that this warning has been part of -Xlint since 2.11, though, so it hasn't been only behind that one obscure flag.

Duplicate of scala/scala-dev#496, I'd say.

I see your point, but that one's targeted for 2.13.1. I opened this ticket specifically to ask what we're going to do for 2.13.0-RC1/2.13.0, since changes have already been made in this area in the milestones.

[dwijnand]

I think that one should target RC1.

[adriaanm]

For migration to dotty, we can adjust adaption use -Xsource. Since we're out of time for RC1, re-scheduling for 2.13.1. If someone manages to fix this for the RC1, that's fine too, but we won't hold up the RCs for this.

[SethTisue]

@szeiger's Scala Days talk has a slide on this. from https://downloads.lightbend.com/website/scaladays/2018/ny/slides/migrating-to-scala-2-13.pdf

[szeiger]

@adriaanm Does it even make sense to revert this in 2.13.1 (or later) now that 2.13.0 shipped without the option?

[SethTisue]

(IMO yes. most open-source libraries are already on 2.13, but most Scala users aren't yet)

[adriaanm]

As useful as this is, I don't want to regress on our policy, nor remove the pressure to actually implement the migration under -Xsource. For now, the warning + fatal warning will have to suffice.

[szeiger]

I don't follow. Are you proposing that certain source levels enable or disable the warnings automatically? If so, which ones?

[adriaanm]

No, I wasn't thinking of the warnings. They are still available, right? I'm referring to the change to the adapt logic that actually prevented the insertion of () or tupling of args.

A "future" (i.e. 2.14 or 3.0) source level will implement (a refinement of) the policy implemented by -Yno-adapt-args, and I feel we should focus our energy on getting that done.

We're talking about not inserting () (except for java-defined methods) and not auto-tupling args (except for, erm, what were the conditions again? I guess only for cases where a Tuple was expected or where we know only a single argument is allowed, e.g. infix methods).

[szeiger]

So you're saying we should not restore -Yno-adapt-args on principle? Judging by the changes in scala/scala#6505 it should only take a few lines of code to get it back. Or maybe there were more changes in the meantime that would make this infeasible?

[adriaanm]

You're right, it would not be a lot of work to bring back, but then there's less incentive to switch to the -Xsource mechanism, which provides a more coherent upgrade-prep experience.

[eed3si9n]

There's apparently a single use case where auto-tupling is useful, so I suggested in https://contributors.scala-lang.org/t/lets-drop-auto-tupling/1799/14?u=eed3si9n that we create an opt-in marker called scala.reflect.ParamList[_]:

def foo[A](params: A): Unit = println(params.toString)
def bar[A: ParamList](params: A): Unit = println(params.toString)

so

foo(1, "hello", Option(3)) // won't compile
bar(1, "hello", Option(3)) // prints (1, "hello", Option(3))

[szeiger]

While we're still considering things, I'm rescheduling this for 2.13.2.

[SethTisue]

given that we still have -Ywarn-adapted-args, and now that we have configurable warnings, I think this qualifies as fixed

[yanns]

I also wanted to have something like -Yno-adapted-args in scala 2.13.

given that we still have  -Ywarn-adapted-args

For me it does not work:

[error] bad option: '-Ywarn-adapted-args'

The new configurable warning convention does not work:

[error] bad option: '-Wadapted-args'

I could use -Xlint:adapted-args

[SethTisue]

I could use -Xlint:adapted-args

right. thank you for the correction

but note also that it's included in -Xlint's defaults, so it doesn't normally need to be individually enabled:

Welcome to Scala 2.13.2-bin-a789d81 (OpenJDK 64-Bit Server VM, Java 1.8.0_242).
scala> println(1, 2)
(1,2)
scala> :replay -Xlint
replay> println(1, 2)
               ^
        warning: adapted the argument list to the expected 2-tuple: add additional parens instead
                signature: Predef.println(x: Any): Unit
          given arguments: 1, 2
         after adaptation: Predef.println((1, 2): (Int, Int))
(1,2)

as for the turning the warning into an error, -Werror will turn all warnings into errors, and the incantation for turning just this particular warning into an error is -Wconf:cat=lint-adapted-args:e:

scala> :reset -Xlint -Wconf:cat=lint-adapted-args:e
Resetting interpreter state.
Forgetting all expression results and named terms: $intp

scala> println(1,2)
              ^
       error: adapted the argument list to the expected 2-tuple: add additional parens instead
               signature: Predef.println(x: Any): Unit
         given arguments: 1, 2
        after adaptation: Predef.println((1, 2): (Int, Int))

note that I'm running a nightly build, since 2.13.2 isn't released yet

[SethTisue]

[error] bad option: '-Wadapted-args'

yeah — it isn't clear to me why some things are -W flags and other things are under -Xlint instead. @som-snytt is there some rule there?

[som-snytt]

Warnings that are not noisy and also "recommended" can be promoted to lint.

E.g., -Wunused:params is not enabled by -Xlint:unused (as a very refined case).

-Wdead-code has false positives, so is not linted.

The borderline promotable warnings IMHO are numeric-widen and value-discard.