Dotty: 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: https://github.com/lampepfl/dotty/pull/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 https://github.com/scala-native/scala-native/issues/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 [e-mail] wrote:

Closed #10239 https://github.com/lampepfl/dotty/issues/10239 via 67017d7
https://github.com/lampepfl/dotty/commit/67017d72719a4b780caf4ad4e27e9a24aaab89a0
.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/lampepfl/dotty/issues/10239#event-3975383245, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAYAUGHUOZN5UMLBOARSITSPA5U5ANCNFSM4TPFF5YQ
.

[som-snytt]

@smooshin is the underlying concept.