Deprecate infix named args #21565
Deprecate infix named args #21565
Conversation
som-snytt
force-pushed
the
discussion/19072-infix-named-arg
branch
from
2cfa491 to
4d25ea3
Compare
|
Probably better as an external lint. |
|
With named tuples this becomes more urgent. I agree, we should deprecate that syntax. |
Looking at #21681, seems like this is common enough to require a compiler warning. Would you like to revive this PR? (Otherwise I am happy to do it.) |
|
The warning at parser goes unseen in October because the arg is now a unituple. (I don't even know the lingo yet.) So the warning info is only meaningful as an addendum to the error here. The warning should be backported to LTS. I'll try that after a second coffee. |
som-snytt
force-pushed
the
discussion/19072-infix-named-arg
branch
2 times, most recently
from
67ba634 to
1d8838c
Compare
|
There is not much to addend, as it turns out. Mention the named arg, in case they didn't count the parens; handle the very contrived example where the param name and the tuple element name coincide. |
som-snytt
force-pushed
the
discussion/19072-infix-named-arg
branch
from
1d8838c to
4448c8b
Compare
|
Should be a migration warning (not deprecation); should not warn on named tuple ops. Probably move the warning to typer (as I meant to do) (or I was thinking refchecks, but it needs to see infix ops). |
SethTisue
added
the
backport:nominated
|
I've added the "backport:nominated" label, but note the discussion on #21826 about whether this change should even be considered eligible for backporting. @som-snytt is this one ready for review? I guess it isn't, actually, because we need to decide on:
above, @odersky suggested deprecation, but I'm not sure if he had considered the "migration warning" option, or was just expressing a general "we should phase this out" opinion the advantage of actually deprecating is that more users will see the warning the disadvantage of actually deprecating is that some users will be annoyed |
…21949) Best effort migration rewrites based on prior work in #21565 At this point, it's too late to deprecate named infix arguments. Let's produce warnings instead. We accept infix arguments that might be an argument of a named tuple, eg. `zip`, `++` or `==` - each of these takes a single argument with NamedTuple. --------- Co-authored-by: Som Snytt <[email protected]> Co-authored-by: Matt Bovel <[email protected]>
…21949) Best effort migration rewrites based on prior work in #21565 At this point, it's too late to deprecate named infix arguments. Let's produce warnings instead. We accept infix arguments that might be an argument of a named tuple, eg. `zip`, `++` or `==` - each of these takes a single argument with NamedTuple. --------- Co-authored-by: Som Snytt <[email protected]> Co-authored-by: Matt Bovel <[email protected]> [Cherry-picked 5d5a9e6]
…cala#21949) Best effort migration rewrites based on prior work in scala#21565 At this point, it's too late to deprecate named infix arguments. Let's produce warnings instead. We accept infix arguments that might be an argument of a named tuple, eg. `zip`, `++` or `==` - each of these takes a single argument with NamedTuple. --------- Co-authored-by: Som Snytt <[email protected]> Co-authored-by: Matt Bovel <[email protected]>
…cala#21949) Best effort migration rewrites based on prior work in scala#21565 At this point, it's too late to deprecate named infix arguments. Let's produce warnings instead. We accept infix arguments that might be an argument of a named tuple, eg. `zip`, `++` or `==` - each of these takes a single argument with NamedTuple. --------- Co-authored-by: Som Snytt <[email protected]> Co-authored-by: Matt Bovel <[email protected]>
Addresses #19072
Ports scala/scala#10857