Skip to content

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

Open
wants to merge 2 commits into
base: language-reference-stable
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
45 changes: 39 additions & 6 deletions docs/_docs/reference/other-new-features/trait-parameters.md
Original file line number Diff line number Diff line change
Expand Up @@ -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:
Copy link
Member

@bishabosha bishabosha Jun 19, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the trait T is parametrised such that new T{}

I don't really like this because this is syntax sugar for the actual thing which is { class $anon extends T; new $anon}

Copy link
Contributor Author

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 because class _ extends T{ } is allowed ?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah

Copy link
Contributor Author

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

* 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):
Expand All @@ -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
Copy link
Contributor Author

Choose a reason for hiding this comment

The 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

Copy link
Member

Choose a reason for hiding this comment

The 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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This one ?
#14840

Copy link
Member

Choose a reason for hiding this comment

The 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?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TODO(@Sporarum): Check this