Heuristics for transparent type aliases #16858
makingthematrix
started this conversation in
General Discussion
Replies: 1 comment
-
So since this has quite a bit of comments in https://contributors.scala-lang.org/t/transparent-term-aliases/5553, I might suggest that instead of commenting in here, we actually focus on the conversation in the contributors forum. Than way everything is in one place and we don't need to jump back and forth. So if anyone is stumbling on this and would like to add some more details or comments, please do so in the forum. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
This is a topic we raised recently at a Tooling Sync Meeting and the conclusion was that we should continue talking about it here so that more people can be involved.
In short, in Scala 2 - especially in collections but not only - we have a pattern of creating a type alias for a class and accompanying it with a value - a reference to that class' companion object. This works in a similar way to exports in Scala 3. In both cases (this pseudo-export pattern and actual exports in Scala 3) when user navigates to the origin of a symbol, in the IDE we need to answer the question should we take the user to the export / pseudo-export or should we skip it and take the user to the original implementation. The second option is a better one in most cases, but sometimes impossible - e.g. a
val
can be overriden, so we can't skip it, and semantics of exports are not clear enough in all cases.You can find a more detailed description here
There was also a discussion recently at Scala Contributors forum
This issue was raised by the IntelliJ Scala Plugin team, but Metals deals with exactly the same problem. It would be great if we could work out a common solution.
Beta Was this translation helpful? Give feedback.
All reactions