A while ago the proposal was made replace inheriting multiple traits using with with using , . Partly because that is what other languages do. But mostly because with was considered as a keyword for the new implicit system.
However the new implicit system seems to have settled on using and given, so the last argument is not valid anymore. Also using a comma can be pretty confusing with tuples. The difference between a list of tuples and a list of items inheriting from two parents is much more difficult to distinguish.
trait A
trait B
// In Scala2
val myList: List[A with B]
val myList2: List[(A, B)]
// Currently in Dotty this looks more like a list containing an A and a B instead of a list of A with B
val myList: List[A, B]
val myList2: List[(A, B)]
Since Scala 3 seems to go towards using words instead of symbols (quite syntax, end blocks with the new optional braces, and the recently proposed as instead of @), this seems less consistent (and IMO) more confusing. So I am in favor of keeping it as is.
I canât find any topic in Contributors where this was actively discussed, if I have missed something feel free to close it (and point me to the actual discussion).
Iâm not familiar with the proposal to replace with with a comma, but IIRC, there was a proposal to distinguish between:
(1) cases where a type is extended and the order matters where a method implementation overrides another, i.e. after extends and in anonymous class instantiations
(2) other cases, where with is just a type union, such as in type ascriptions and as type argument, where the order does not matter
and for (2), it was proposed to replace A with B by A & B. Iâm guessing for (1) only, we would replace it by A, B.
So, it would be:
class C extends A, B
val ab = new A, B { ... }
val list: List[A & B] = ...
val ab = c: A & B
For the moment, the dotty compiler accepts both , and with after extends. I argue that we should switch to , for the following reasons:
, is standard. Thereâs no need to be different for the sake of being different.
, reads better
, saves us a keyword; weâd no longer need with (after a transition period).
The one downside is that anonymous classes with multiple parents would be no longer supported. We cannot simply replace
new A with B { ... }
with
new A, B { ... }
without running into abiguities. On the other hand, that does not work in Java either, so one should ask oneself whether anonymous classes with multiple parents is a unique Scala signature feature thatâs worth preserving. Note that we can always replace that idiom in Scala with
{ class C extends A, B { ... }; C() }
Thatâs a faithful translation; the anonymous class translates exactly into this.
This is a good point, I didnât realize we would use & for the type. So my previous point is moot.
This is rather subjective and I disagree. Also the new quit syntax introduces then, so it seems rather arbitrary to replace with with a symbol and introducing then to replace parentheses. Generally Scala seems to favor words over symbols, and I personally think this is a good thing. Its slightly longer, but easier to type and easier to read, again IMO.
I think it is worth preserving. I find that we use anonymous classes quite often (mostly for stacking mixins or the âmodule patternâ) and removing it would introduce unnecessary boilerplate.
Thatâs not a faithful translation when A and B are JavaScript types in Scala.js. The original code directly instantiates A and creates additional fields and methods on the resulting instance, whereas the replacement creates a separate class, then instantiates that class. The semantics are different and are observable. Sometimes, the additional class can cause the object not to be accepted by a JavaScript library, which might for example throw a TypeError.
In those case, the only faithful translation is
new A { ... }.asInstanceOf[A & B]
which is not type-safe.
In either case, the âworkaroundsâ are not nice.
Compare the argumentation in this thread to the one in https://github.com/lampepfl/dotty/issues/9829 about renaming @ into as, and the alternative proposal to use something with the semantics of &. In that thread, you argue that the elegant & solution cannot be considered because it prevents the use case
private val (_, captured @ _, noInits @ _) = newFlags(32, "<captured>", "<noinits>")
val Captured = captured
val NoInits = noInits
Is that pattern more worthy than the anonymous class with two parents? Is the workaround uglier? What makes this pattern worth blocking a semantically elegant improvement, and the anonymous class with two parents pattern not worthy of blocking a purely aesthetic change?
What if we allowed new (A, B){} to satisfy the multiple-parent-anonymous class use case? after all Tuple types are final and cannot be subclassed, and even if they could we could tell people to do new Tuple2[A, B]{} instead if they really want to extend tuples
I find that new (A, B){} looks a bit awkward. If we must keep multi-parent anonymous classes, another possibility is to stick with the status quo, and keep with as an alternative to ,. The downside would be multiple ways of doing things.
On the other hand, since â,â is shorter, easier to read, and more standard, I would expect most people to change over to it, over time.
So itâs equivalent in Scala, but not in Scala.js? So, if Iâm using Scala.js, innocent refactorings such as replacing an anonymous class by a non-anonymous one may change the behavior of my code? That sounds worse to me than lack of type safety.
I agree that new (A, B){} is a bit awkward, but I personally instantiate anonymous multi-parent classes rarely enough that I think itâs worth the tradeoff if it lets us properly kill with and helps us standardize on ,
Again, I donât think this is universal truth, and also a bit inconsistent with the other changes coming in Scala 3 (as, if then else, end, do).
On the other hand, this syntax bike-shedding will never make everybody happy. So Iâll take my loss here. When a choice is made I hope that it is consistent across all use cases. Thus either , everywhere, or with everywhere.
I think the word class itself has wrong semantics for something that only appears once. object C extends A, B { } would be better.
In both cases the name is superfluous. Naming is hard, and names here might end up like TheThing or AandB. This decreases readability, as someone reading the code might ask âwhat does this name mean? why is it named this?â and having to spend more mental capacity to make sure they understand the intention of the code. object _ extends A, B { } might work but is more cryptic.
It is equivalent in Scala.js as well for Scala classes, i.e., classes that extend AnyRef or AnyVal. For those, the behavior will be the same in both cases. This is of course necessary to keep portability with Scala/JVM.
It is different for JavaScript classes, i.e., classes that extend js.Any. And for those, equivalence with JavaScript semantics is paramount (that is the very purpose of JS types). In that case the ârefactoringâ is not a refactoring. It is a semantic change.
All along we were told that we needed two separate type operators because & has different semantics than with. The order of types does not matter with &, however with does trait linearization so the order matters.
But if weâre not retaining with as a type operator, and if extends uses commas, then thatâs just syntax. In other words the part after extends is no longer a single type expression involving with, itâs simply a list of types to extend, then why not use &? Itâs true that order in extends matters but whereâs the pitfall exactly?
If we donât need with then why canât we just use & everywhere?
As someone that writes Scala some of the time, Iâm not really a fan of something like { new A, B { ... } } or new (A, B) { }. I think that I would find these both a bit cryptic and perhaps too easy to confuse with other things (e.g., tuples). In that sense I think that using âwithâ is better for users less familiar with the language.
Also, if anonymous classes with multiple parents is not really used very much then I would probably be in favour of just deprecating it. Each feature removed from a language makes it slightly less complicated.
For me, I mentally think of âwithâ as adding in a trait (or traits), and I find it strange that a class can âextendâ a trait. I can see that a class can extend a class (and mix in traits) and a trait can extend a trait (or traits), but it feels strange for a class to extend a trait rather that implement or use the trait.
So, without thinking about this too deeply, I guess that I would ideally like a syntax something like:
trait T1
trait T2
trait T3 extends T1
trait T4 extends T1, T2
// Or perhaps trait T4 extends T1 with T2, e.g. if T2 was a super trait
class C1
class C2 extends C1
class C3 extends C1 with T1, T2
class C4 with T1, T2 // Not allowed today.
new C1 with T1 {}
new C2 with T1, T2 {}
Not sure if this input is helpful, but perhaps a different perspective âŚ
Then perhaps new C2 with (T1, T2) {} \\ or new (C2 with T1, T2) {}
I.e., I think that having the âwithâ gives a better clue about what is going on, and is also easier to search potential documentation for.
When I look at languages that Iâm no longer familiar with then some of them have many symbols that make it very hard to get any sort of idea about what is going on (e.g., possibly some of the stuff added more recently to C++).
If we are using & where the order doesnât matter (i.e. as type ascription or type argument), maybe we can use :& where the order does potentially matter (i.e. after extends or in anonymous class instantiations).
I think thatâs intuitive: itâs clear that & and :& are similar, that & is commutative (because it usually means bitwise AND) and :& is not commutative (because operators with preceeding colons are usually not commutative).