Skip to content
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

Change "super trait" to be annotation-based #10239

Closed
sjrd opened this issue Nov 9, 2020 · 7 comments
Closed

Change "super trait" to be annotation-based #10239

sjrd opened this issue Nov 9, 2020 · 7 comments

Comments

@sjrd
Copy link
Member

sjrd commented Nov 9, 2020

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
Copy link
Member Author

sjrd commented Nov 9, 2020

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
Copy link
Member

bishabosha commented Nov 9, 2020

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

@odersky
Copy link
Contributor

odersky commented Nov 9, 2020

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
Copy link
Member Author

sjrd commented Nov 9, 2020

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
Copy link
Contributor

odersky commented Nov 9, 2020

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
Copy link
Member Author

sjrd commented Nov 9, 2020

Hum ... all right.

@odersky odersky closed this as completed in 67017d7 Nov 9, 2020
odersky added a commit that referenced this issue Nov 9, 2020

Verified

This commit was signed with the committer’s verified signature.
RaisinTen Darshan Sen
Fix #10239: `@mixin trait` instead of `super trait`
@nafg
Copy link

nafg commented Nov 9, 2020 via email

michelou pushed a commit to michelou/scala3 that referenced this issue Nov 12, 2020

Verified

This commit was signed with the committer’s verified signature.
targos Michaël Zasso
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants