Fix #12344: tune splicing of default getters #12353
Conversation
| def test3a(using q: Quotes) = new C(1, q.reflect.Flags.Lazy) // error | ||
| def test4a(using q: Quotes) = new C(f = q.reflect.Flags.Lazy) // error | ||
|
|
||
| def test1b(using q: Quotes) = C() // error |
There was a problem hiding this comment.
Why is there an error with this one?
There was a problem hiding this comment.
It seems like it should compile.
There was a problem hiding this comment.
As you mentioned in #12344 (comment), for the default parameters to apply, we do need double ():
def test1e(using q: Quotes) = new C()()
def test2e(using q: Quotes) = C()()
There was a problem hiding this comment.
That goes against the design philosophy of using clauses though doesn't it? My understanding is that if using isn't specified at call-site then it shouldn't map to the using param clause. Having the first () map to the using q clause breaks that rule.
There was a problem hiding this comment.
@japgolly I think there is no such mapping. It seems the ctor gets an initial empty param list that is not written, see the linked comment. The first explicit params in the call correspond to that one. This is perhaps more natural in Scala 2 where you expect auto-application and only one implicit at the end, so new C makes sense as new C()(implicits). I see it must still be explicit in Scala 3 for case class: "A case class must have at least one non-implicit parameter list".
There was a problem hiding this comment.
Given a definition like the following:
class C(using Int)
object CWithout prepending the constructor with(), the identifier C would be ambiguous (Scala 3 generailzes synthetic apply to all classes to avoid new).
For the example reported in #12344, the implicit parameter list comes after the synthetic empty parameter list (), and finally follows the default parameter list.
| def test4d(using q: Quotes) = C(using q)(f = q.reflect.Flags.Lazy) | ||
|
|
||
| def test1e(using q: Quotes) = new C()() | ||
| def test2e(using q: Quotes) = C()() |
There was a problem hiding this comment.
Similarly, I understand that these work now but that's part of the bug - these 2 lines shouldn't work. There's only one non-using param clause, it shouldn't be possible to specific two non-using clauses at call-site.
|
@nicolasstucki Could you have a look at this again? |
Fix #12344: tune splicing of default getters