Compiler doesn't generate error "takes type parameters" in extends list

[unkarjedy]

Scala 3.3.3 or 3.6.2

trait MyTrait[T]
class MyClass extends MyTrait //No error =/ Apparently Scala 3 treats it as `extends MyTrait[Nothing]`
val value: MyTrait = ??? //this is an error though

Actual behaviour
No error for extends MyTrait.
It's treated as MyTrait[Nothing]

Expected behaviour
Scala 3 compiler should generate the error "trait MyTrait takes type parameters" like in Scala 2.
Or "Missing type parameter for MyTrait" as for val value: MyTrait

It might be some unintended side-effect of changes in kind polymorphism in Scala 3.

Originally asked in Discord:
https://discord.com/channels/632150470000902164/632150470000902166/1327234334758797322

[Gedochao]

Interesting. This seems to be a pretty old regression (unless it's an intended change I don't know about).

Last good stable release: 3.3.0
Last good nightly release: 3.3.1-RC1-bin-20230209-3d251d6-NIGHTLY
First bad nightly release: 3.3.1-RC1-bin-20230213-8c616bf-NIGHTLY
First bad stable release: 3.3.1

The bisect script crashes in between on SbtParser, the faulty commit is one of 3d251d6..8c616bf:

• 3d251d6
• 116a960
• f77069a
• d6ee51e
• 2678e67
• ad675af
• 4e8e201
• afd499b
• bdd56dd
• a2c89fb
• c5c5aa6
• 25542cb
• 6c241d3
• ae05f99
• f177d96
• 97641d3
• 4b8a31f
• d6ae0cb
• 1451788
• 79bad18
• 2d641ec
• 1a4f3ac
• ea87c08
• 00d3079
• 5c69746
• 3bdd913
• 46e82dd
• c830ad2
• 5a8e53e
• 8c616bf

cc @som-snytt @smarter @odersky @dwijnand

The range is quite wide, might need some effort to narrow this down.

[dwijnand]

It's not kind polymorphism, it's type arg inference - and Nothing is a valid type argument. I feel like this has been seen before and we decided to not change it, but I don't have an issue reference.

[odersky]

We could potentially rule out type arg inference if there are no term arguments that follow. After all, there's nothing to infer then and we always end up with Nothing which is often not helpful.

I am not sure there was an explicit discussion about this in the past?

[dwijnand]

I am not sure there was an explicit discussion about this in the past?

I'm probably thinking of #3434 (comment).

We could potentially rule out type arg inference if there are no term arguments that follow. After all, there's nothing to infer then and we always end up with Nothing which is often not helpful.

Sounds good to me (also not changing anything sounds fine to me too).

[odersky]

The discussion on #3434 seems to imply that at least in 2017 the Scala 2 compiler did infer Nothing. It seems that has changed. But since we did somehow issue an error for this in 3.3, I don't believe there's a good reason change that. So I think we should demand fully typed applications if no term parameter list is given.

[unkarjedy]

BTW, the original code example is taken from here:
https://docs.scala-lang.org/sips/named-tuples.html#appendix-b-embedded-queries-case-study

I noticed IntelliJ reporting the error while the code compiles:

[noti0na1]

The regression may be related to this issue #16778 and PR #16896

It seems Scala 2 will infer the type arguments if the parent type is not a trait:

trait MyTrait[T]
class MyClass1 extends MyTrait // error in Scala 2

abstract class MyAbsClass[T]()
class MyClass2 extends MyAbsClass

[noti0na1]

I think we have three choices:

• Revert back to: don't infer if no term parameter list is given. This is the most reasonable choice personally;
• Keep the current behaviour: always infer for parent types, so we don't break any code relying on our previous fix;
• Or, copy the exact behaviour of Scala 2: infer the type arguments if the parent type is not a trait.

[noti0na1]

After #16896, both Scala 2 and 3 are trying to infer type arguments for the parent types, so they have the same behaviour in this sense. The reason why Scala 3 doesn't give error when extending the trait is because traits have constructors in Scala 3 but not in Scala 2.

After discussion at the core meeting, we decided to keep the current Scala 3 behaviour to avoid breaking any existing code.