Change "super trait" to be annotation-based

[sjrd]

At the last SIP meeting, we concluded that the functionality of super traits was desirable but it

• should be annotation-based
• should not be named "super trait"

We need to make sure to do this before we release 3.0.0-RC1.

We have not decided on a name for the annotation.

[sjrd]

Here are some suggestions of names, coming from the PR that introduced super traits: #9032

• @implementationTrait
• @mixinTrait
• @noInfer / @doNotInfer

My opinion would be to go with @doNotInfer. It is self-explanatory: it tells the compiler not to infer that trait.

[bishabosha]

And then there is shape from the original paper, but that's esoteric.

[odersky]

I think @mixin would work. It tells you that the trait is only understood as a mixin to something else, but not as a standalone type.

[sjrd]

I'm not sure that reasoning applies to some of the built-in types that we are targeting. Is it a valid reasoning for Product? For Comparable?

I would also like to apply it to java.lang.constant.Constable because inferring it causes issues in Scala Native and Scala.js (see for example scala-native/scala-native#1938): does it apply for that one?

[odersky]

I'm not sure that reasoning applies to some of the built-in types that we are targeting. Is it a valid reasoning for Product? For Comparable?

I think so. doNotInfer is a bit unspecific. The meaning is that a mixin trait M will be dropped in an inferred type if it is used as a mixin. I.e. if the inferred type would be A & M we widen to A, but if it is M we leave it as it is.

[sjrd]

Hum ... all right.

[nafg]

IMO this is a very confusing name. Any trait that is meant to be mixed into a class is called a mixin by people. I guess I'm too late but I would have suggested "auxiliary" or something in that direction. The difference between traits like Product and HasSummaryAndDetailStrings or SeqLike is not whether they are a mixin. And if I have a list of things that only have Product in common I want it to be inferred. The question should only be what to infer when there are other types to infer. So the question is about making some traits second-tier when inferring a union type or LUB. Hence I would use a name that suggests secondary-ness, like auxiliary.

…

On Mon, Nov 9, 2020 at 2:15 PM odersky ***@***.***> wrote: Closed #10239 <#10239> via 67017d7 <67017d7> . — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#10239 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAYAUGHUOZN5UMLBOARSITSPA5U5ANCNFSM4TPFF5YQ> .