Collection meeting

[szeiger]

Since @julienrf is still on vacation and nobody else seems to be around for a meeting today, let's start collecting topics for the next one:

• PF type inference problems in Dotty: Add collect #117 - I fixed it in Scala 2.13 but the Dotty typechecker is quite different and it wasn't clear to me if it's the same bug or something different

• State of collection laws

• It looks like all the design problems are solved so we can take the risk of adding more code. Are Spandex (ArraySeq (f.k.a. Spandex) #52), Steque (Steque 2 #88) and ArrayDeque (SI-10167: Implement mutable.ArrayDeque #49) good to clean up and merge? (This doesn't mean they would be merged into Scala in this state; we need to decide what to keep and under which name after we have more comprehensive benchmark results)

• By-name right-associative operators in Dotty? LazyList.#:: not lazy due to parser rewriting of right-associative infix operators #127

• Merge withFilter (Add withFilter #165)?

• Merge StrictOptimizedSeqOps (Add StrictOptimizedSeqOps #161)? Only two of the three overrides are actually used by a concrete collection (List)

• Priority of implicits (see Implicit factories #168)

[odd]

Spandex (#52) is good to go.

[julienrf]

Thanks @szeiger for taking care of that :)

It looks like all the design problems are solved

I’m still not sold on the way we integrate String and Array decorators and the way we implement the View hierarchy. (see #134 and #78)

State of collection laws

FTR, I created a branch to integrate unit tests (here) but I didn’t integrate https://github.com/scala/scala-collections-laws in it (yet). We should obviously add these tests, but the infrastructure looked a bit more complex than the unit tests.

By-name right-associative operators in Dotty?

PF type inference problems in Dotty

Could you open issues in the Dotty repo? (maybe you already did that, I didn’t check)

[Ichoran]

I'm working on collections-laws. I have permission from Adriaan to rework it (with the sourcecode macros I can put a lot more out of weird custom config files and into Scala code without losing good error reporting--actually it's close to a complete rewrite of the code-generation logic). Once I'm done with that, I'll port it to the strawman collections. Pre-rewrite, it's pretty unfriendly.

[julienrf]

Hey, if you have time to review #165 before the meeting that would be great!

[pathikrit]

ArrayDeque is good to go (#49). Honestly ArrayDeque is better stack than current mutable.Stack and a better queue than current mutable.Queue and can also serve as a drop-in replacement for ArrayBuffers.

[julienrf]

@Ichoran Would you have some time to review #49? I think that would be valuable.

[Ichoran]

@julienrf - I won't be able to get to it until tomorrow evening. Hopefully I'll have a long enough block of time then.

[Ichoran]

@julienrf - Didn't quite make it to the end but I think I hit all/almost all the important and semi-important points.