-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Update reference for ommiting trait parameters #17988
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
base: language-reference-stable
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -53,13 +53,19 @@ The correct way to write `E` is to extend both `Greeting` and | |
class E extends Greeting("Bob"), FormalGreeting | ||
``` | ||
|
||
## Traits With Context Parameters | ||
## Default values and implicit parameters | ||
|
||
This "explicit extension required" rule is relaxed if the missing trait contains only | ||
[context parameters](../contextual/using-clauses.md). In that case the trait reference is | ||
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: | ||
* Parameters with default values are set to their default value. | ||
* [Context parameters](../contextual/using-clauses.md) are set to the value present in the implicit scope. Notably from class parameters or other traits. | ||
|
||
```scala | ||
trait withLastName(val lastName: String = "") | ||
|
||
case class Person() extends withLastName | ||
// identical to | ||
case class Person extends withLastName("") | ||
``` | ||
|
||
```scala | ||
case class ImpliedName(name: String): | ||
|
@@ -83,6 +89,33 @@ class F(using iname: ImpliedName) extends | |
``` | ||
Note the inserted reference to the super trait `ImpliedGreeting`, which was not mentioned explicitly. | ||
|
||
In the above context, the following is also valid: | ||
```scala | ||
given iname: ImpliedName | ||
class F2() extends ImpliedFormalGreeting | ||
``` | ||
And expands to: | ||
```scala | ||
class F2() extends | ||
Object, | ||
ImpliedGreeting(using iname), | ||
ImpliedFormalGreeting | ||
``` | ||
|
||
Forms of ommission can be combined: | ||
```scala | ||
trait SuperTrait(using Char)(val name: String = "")(using Int) | ||
|
||
given c: Char = 'X' | ||
class SuperClass(using i: Int) extends SuperTrait | ||
``` | ||
The last line expands to: | ||
|
||
```scala | ||
class SuperClass(using i: Int) extends SuperTrait(using c)("")(using i) | ||
``` | ||
|
||
## 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. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This one ? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. yeah, I didn't check, but maybe this is the cause for a change? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. TODO(@Sporarum): Check this |
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh I see, so it is actually the other way around ?
new T{ }
is allowed becauseclass _ extends T{ }
is allowed ?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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