Update reference for ommiting trait parameters #17988
Conversation
Sporarum
force-pushed
the
Sporarum-patch-trait-params
branch
from
6d7202a to
4bbcdea
Compare
| ## Reference | ||
|
|
||
| For more information, see [Scala SIP 25](http://docs.scala-lang.org/sips/pending/trait-parameters.html). | ||
| TODO: Find which PR changed the behaviour, as this was changed between 3.2.2 and 3.2.1 |
There was a problem hiding this comment.
If someone with more knowledge of this area of the compiler could pinpoint this, I would be very grateful
There was a problem hiding this comment.
I thought this would be related to the PR that changes the constructor parameter encoding when parameters begin with a using clause
There was a problem hiding this comment.
yeah, I didn't check, but maybe this is the cause for a change?
There was a problem hiding this comment.
TODO(@Sporarum): Check this
|
this fixes it: new Obj()(){}
case class Test(x: Int) extends Obj()() |
Yes, that's what I mean by the following ^^'
But you'll note this is not my main problem with the current reference |
|
@bishabosha As always 1) correctness and 2) readability/clarity/etc |
| implicitly inserted as an additional parent with inferred arguments. For instance, | ||
| here's a variant of greetings where the addressee is a context parameter of type | ||
| `ImpliedName`: | ||
| If the trait `T` is parametrised such that `new T{}` would be a legal annonymous class creation, the "explicit extension required" rule does not apply, the parameters filled in as for the annonymous class: |
There was a problem hiding this comment.
If the trait
Tis parametrised such thatnew T{}
I don't really like this because this is syntax sugar for the actual thing which is { class $anon extends T; new $anon}
There was a problem hiding this comment.
Oh I see, so it is actually the other way around ?
new T{ } is allowed because class _ extends T{ } is allowed ?
There was a problem hiding this comment.
Hmmm
Then the "obvious" spec would be "if all clauses can be inferred or called as (), they can all be ommitted", but this is not actually the case, as we can see from #18006
|
(opened parens issue: #18006) |
This is what I found out by experimenting, I did not look into the compiler to see what is actually done (which can be a good or bad thing)
Here is what I could come up with:
https://scastie.scala-lang.org/fEEqASMSTCWYuiZjDcRPbA
We can see there is a strong correlation between
new T{}andextends Tbeing allowed or disallowed.I found it surprising that
new Obj2{}is valid, whilenew Obj{}is not, given they are both valid withnew ...()(){}, should I open an issue for that ?