Warn about change to parenless lambda parens under -Xsource:3

[som-snytt]

The syntax xs.map { x: Int => x + 1 } is disallowed in Scala 3.

Parenless params are deprecated under -Xsource:3, and will error if -Wsource is added.

Without -Xsource:3, -Wsource will warn.

The message is, "parentheses are required around the parameter of a lambda".

[SethTisue]

I find this change of the more annoying things about Scala 3, so I can't get enthusiastic about having this warn by default. wdyt about staying silent by default, and warning under -Xsource:3?

The reasoning would be that it's only worth warning by default if the change in question is considered desirable even purely in a Scala 2 context.

[som-snytt]

if the change in question is considered desirable

Somewhere I gave the example that changed my mind. Too bad everything is lost on discord. Oh maybe it's in this PR.

I would like -Wconf:cat=parans:s, but IIUC right now deprecation is the category? I wonder if I can create subcategories of deprecation, so that I can selectively suppress this particular deprecation.

I will experiment forthwith. If that is feasible, then I would assert that deprecation is correct albeit annoying. Parenless was one of my favorite syntax niches, as attested by my SO answers from 2012.

[SethTisue]

@lrytz opinion?

[som-snytt]

No fair asking Dad.

I'm hoping a Wconf tweak will allow a cat to match on deprecation and message, rather than emitting a special cat.

[som-snytt]

Maybe @lrytz also has an opinion on nuanced category matching.

Matching on category (effectively an enum) is less error-prone than matching the message string.

[lrytz]

For the new ambiguity warning I added Or use -Wconf:msg=legacy-binding:s to silence this warning to the message, then we don't need a new category. WDYT?

wdyt about staying silent by default, and warning under -Xsource:3?
The reasoning would be that it's only worth warning by default if the change in question is considered desirable even purely in a Scala 2 context.

I actually tend to agree with this sentiment.

Why do you think a: A => b: B => exp is bad?

[som-snytt]

I considered that the "to silence" suffix is cut/paste advice, but we don't always have the privilege of pasting. On typo, the error message is better with cat. Does that mean all fixed messages should have a cat? LegacyBinding. (Speaking off the cuff, I was sick again (child disease vector) and haven't given it further thought.)

I find the example snippet difficult to parse visually because the second colon is a natural place to break. It's a trivial expression that is non-trivial to read.

On when to deprecate, I lost the grid, but I think if something is going away, it is deprecated, and errors under -Xsource. For example, early definitions. I think it is problematic to second-guess Scala 3 on language choices. The underlying goal is migration. If we don't warn now, then someone's favorite idiom disappears all at once. I observe that parenless param seems to cluster, as though there are just certain spots where it's needed to provide the param type or it fits a style.

[som-snytt]

This is the PR to help the migration story: #10327

In particular { implicit (x: T) => }.

So the two funky Scala 3 features that are suddenly indispensable are indentation checking and -rewrite.

[SethTisue]

I find this change of the more annoying things about Scala 3, so I can't get enthusiastic about having this warn by default. wdyt about staying silent by default, and warning under -Xsource:3?

Having had further time to mull it over, I still feel this way. I don't feel we should annoy our users with this unless they have requested migration information.

There's probably tons of books and blog posts and SO answers and such that use the parenless syntax; the concept that there was anything wrong with that syntax is entirely new with Scala 3.

I don't find the a: A => b: B => exp case persuasive. Yes, that's an example that arguably reads nicer with parentheses, but 98% of the time this is warning is going to be emitted on ordinary lambdas, not on unusual ones like that.

[som-snytt]

I'll detune to avoid annoying people, as I have other ways of doing that.

[som-snytt]

I added -Wsource to mean, "accelerate the warning/error cycle due to -Xsource". Nobody will ever use it or even know it's there, except me. (Don't tell sbt-tpolecat. Tpolecat himself is already on Scala 3.) There might be other borderline warnings; in fact, all of the deprecations for -Xsource have sent a shudder of annoyance down my spine, or is it up my spine. But, until this moment of spinelessness, we have braced for change.

I almost made it a -V option where it's v for virtuous.

Also, followed Lukas in emitting the -Wconf:msg= instead of a cat. Except I must tweak the message for Lukas's clever hack.

[SethTisue]

As you seem to have anticipated, I'm iffy on the need for -Wsource. I'm not sure how much of a fight to put up.

At minimum, I think we'll need a better description than Increase warnings/errors due to -Xsource, which I think users will find almost completely opaque. I know the context and I don't really understand it myself.

Whatever warnings -Wsource enables, why wouldn't a user who wants these warnings enable -Xsource:3? What is the audience for this flag?

[som-snytt]

Edit: I don't care either, so I removed the extra option, one less thing to explain. Also removed my previous comment so I don't have to explain it.

Came close to

Use '-Wconf:msg=lambda-parens:s' to silence this warning, or '-Wconf:msg=lambda-parens:e' to make it an error like it should've been.

The following comment is still germane:

Someone just asked about something that warns differently under -source:3.0-migration, so another option would be -Xsource:3-migration to mean -Wsource or some variation.

[lrytz]

Thanks, I also think in the current form this is good.