Skip to content

forbid default values for extension parameters #12460

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
unkarjedy opened this issue May 13, 2021 · 4 comments · Fixed by #22492
Closed

forbid default values for extension parameters #12460

unkarjedy opened this issue May 13, 2021 · 4 comments · Fixed by #22492

Comments

@unkarjedy
Copy link
Contributor

Compiler version

scalaVersion := "3.0.0-RC3"

Minimized code

Currently this compiles fine:

extension (x: String = "123")
  def f2 = x.reverse

Expectation

Seems that there are no use cases for it and only misleads
Probably a compiler error should be shown here.

@unkarjedy
Copy link
Contributor Author

note that default arguments are still acceptable in using parameters

locally {
    extension (x: String)(using s: String = "default value")
      def f1: String = x.reverse
    
    "my string".f1
  }

@unkarjedy
Copy link
Contributor Author

we may also prohibit by-name parameters in extensions,
because while even a regular argument to a by-name parameter might be surprising,
such as bar(foo()),
it's much more unexpected that foo().bar() might result in calling bar() without calling foo()

@SethTisue SethTisue added the Spree Suitable for a future Spree label Jan 30, 2023
@Sporarum
Copy link
Contributor

Discussing this with @mbovel, we believe we should put these checks in Refchecks
(As opposed to in the parser)

@Sporarum
Copy link
Contributor

You can find our work over there:
#17321

I left some TODOs to point at what still needs to be done

@mbovel mbovel removed the Spree Suitable for a future Spree label Jan 30, 2024
@som-snytt som-snytt self-assigned this Feb 1, 2025
KacperFKorban pushed a commit that referenced this issue Feb 20, 2025
Fixes #12460 

I shied away from making it an error, as that is a language change that
violates the rule that extension methods are ordinary methods. There are
other restrictions, but an extension always allows explicit invocation
`m()(x)` that could leverage a default.

The caret is wrong on the second test case (~todo~). Edit: span of
default getter was union of first parameter and the param RHS, so that
the synthetic position of the getter symbol was a point at the first
parameter. Now the getter tree gets the span of the RHS. (That span is
non-synthetic, but the definition is still synthetic. The name pos of a
synthetic is the point.)
@WojciechMazur WojciechMazur added this to the 3.7.0 milestone Mar 11, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment