Investigate use of super-accessors in traits in the standard library

[smarter]

A super.foo call in a trait will require a super-accessor in every class that implements the trait since the super will be resolved based on the linearization order of the class. In most cases this is probably not what you want, e.g. in https://github.com/scala/scala/blob/d6455592055ce1729ab7ac11d69da3a5a5f3d9dc/src/library/scala/collection/Seq.scala#L187
I suspect what you really meant was:

super[IterableOps].concat(suffix)

Besides possible unwanted semantics and performance impact, super-accessors are also problematic because they cannot always be implemented (this is now detected as of scala/scala3#5604 / scala/scala3#5604), so I think it's worht reviewing their use before RC1 ships since adding or removing super-accesors is binary-incompatible.

[szeiger]

With traits becoming more powerful and class-like, does it even make sense that an unqualified 'super' in a trait refers to the implementing class's linearization order rather than the linearization as seen by the trait?

[smarter]

It's necessary to implement some patterns, but I think it should be more explicit, e.g. dynamicSuper.foo, that's a tricky thing to change though.

[szeiger]

I think https://github.com/scala/scala/blob/d6455592055ce1729ab7ac11d69da3a5a5f3d9dc/src/library/scala/collection/Seq.scala#L187 is correct and requires dynamic resolution. super could either be IterableOps or StrictOptimizedIterableOps. This is the case for must super delegations in collection methods.

I looked through all 184 uses of unqualified super calls in the standard library The following ones occur in traits:

scala.collection  (27 usages found)
    BitSet.scala  (5 usages found)
        172 else super.max(ord)
        178 else super.min(ord)
        244 case _ => super.concat(other)
        254 case _ => super.intersect(other)
        264 case _ => super.diff(other)
    LinearSeq.scala  (1 usage found)
        185 case _ => super.sameElements(that)
    Map.scala  (1 usage found)
        329 override def ++:[B >: (K, V)](that: IterableOnce[B]): IterableCC[B] = super.++:[B](that)
    Seq.scala  (2 usages found)
        187 def appendedAll[B >: A](suffix: IterableOnce[B]): CC[B] = super.concat(suffix)
        780 def lengthCompare(len: Int): Int = super.sizeCompare(len)
    SortedSet.scala  (2 usages found)
        91 else super.min
        97 else super.max
scala.collection.immutable  (101 usages found)
    Seq.scala  (7 usages found)
        55 case otherIndexedSeq: IndexedSeq[_] => length == otherIndexedSeq.length && super.canEqual(that)
        56 case _ => super.canEqual (that)
        89 case _ => super.sameElements(o)
        127 else super.slice(from, until)
scala.math  (1 usage found)
    Ordering.scala  (1 usage found)
        237 private[this] val _reverse = super.reverse

There is not a single one where I would feel 100% confident restricting it to a static supertrait. In most cases the dynamic look-up is clearly desirable.

[szeiger]

There doesn't appear to be anything more to do about this so I'm closing the issue.

[smarter]

I think https://github.com/scala/scala/blob/d6455592055ce1729ab7ac11d69da3a5a5f3d9dc/src/library/scala/collection/Seq.scala#L187 is correct and requires dynamic resolution. super could either be IterableOps or StrictOptimizedIterableOps. This is the case for must super delegations in collection methods.

Hmm, in that case why is concat in that file marked as "TODO: ... Uncomment final" ? (Also the associated issue is closed now, not sure what the status of that is).