Migrating StackOverflow answers to Scala 3

With the move to Scala 3, how can we as a community also migrate the many old StackOverflow answers that exist and refer to syntax that is either deprecated, wrong, or has a better alternative? Is there some way we can organize and rank up answers that are better fit for Scala 3? How do find and keep track of the “bad” answers until better alternatives are provided?


Consider following the example of Xavier Guihot regarding release of 2.13 where he would enrich existing question with “Starting Scala 2.13…” answer, or even ask and answer his own question with 2.13 information (which is encouraged by SO). Community could then upvote such modified questions by keeping an eye on Scala active questions tab.


They could hold Scala Sprees devoted entirely to upvoting Scala 3 Q&As.

The next edition of Scala Puzzlers will have one of those star-shaped stickers on the cover: “Certified for Scala 3!”

Once upon a time, I thought it would be helpful to maintain a list of puzzlers resolved by Scala 3, but it turned out to be more productive to post puzzlers which survive all the Scalafixes you can throw at it.

Full disclosure, I’m not affiliated with either Scala 3 or its Puzzlers. But maybe it’s not too late to stylize it “Pu33lers” in the press materials.

In addition to Mario Galic proposals:

One thing we could do, is introduce next to the scala tag scala-2 and scala-3 tags.

So we can tag questions according to their relevance. At some point scala will then mean scala-3 - I saw that with the playframework tag.

What I also use is if I find an answer, but not in the Technology I am looking for. I just repeat the title with the according Postfix.


Is then:


This seems to be a general problem with SO at large, and without any clear and efficient ways of dealing with it.

I think the best we can do is to list those questions and encourage the community to provide new answers and upvote them (but not downvote outdated answers, they may still be relevant).

How do we approach the community? Uhh… like we do now with twitter, blog posts and the users forum? I’m not sure.

1 Like

Here is my attempt at enriching existing question describing limit 22 as a dropped feature. The answer provides

Perhaps this could serve as a template for further Scala 3 answers.


Update Understanding the Aux pattern in Scala Type System with Bye bye Aux pattern

trait Last[A] {
  type B
  def last(a: A): B

object Last {    
  given [A] as Last[Tuple1[A]] {
    type B = A
    def last(a: Tuple1[A]) = a._1

  given [A, C] as Last[(A,C)] {
    type B = C
    def last(a: (A,C)) = a._2

def sort[A](as: List[A])(implicit last: Last[A], ord: Ordering[last.B]) = as.sortBy(last.last)

sort(List(("ffle",3), ("fu",2), ("ker",1)))
// List((ker,1), (fu,2), (ffle,3))

Could you add a short explanation / reference to another question on why one would use type members instead of type parameters in the first place? I myself am not entirely sure what is the advantage of a type member with the aux pattern over the same encoding via type parameters.

Oh, I wasn’t trying to dispute the necessity of type members. I believe that this is somewhat a natural question that comes up when reading about the aux pattern, so I was thinking it may be worth adding a bit of context to the SO answer.

There is at least a difference in implicit search scopes:

trait Find[A] {
  type B
object Find {
  type Aux[A, C] = Find[A] { type B = C}

class X
object X {
  implicit val find: Find[Int] { type B = X } = ???

def x[A]()(implicit f: Find.Aux[A, X]) = f
x() //error

If Find is encoded with two parameters Find[A, B], then x() will succeed, because X will be in search scope. However, a type member is NOT in implicit scope.

IME, with aux pattern in general the parameter part is much more likely to infer the the type member, than the other way find around, which can happen in parameter encoding, but I don’t have a clear cut example right now

Works in Dotty™ :).

Yeah, but there was a specific change to extend implicit scope with type members. I can’t really pinpoint the mechanism as to how exactly they differ, I’d just start with parameters, get diverging expansion errors, then move to Aux and it works, so that’s just IME

1 Like

I had read that in that paper as well, but I think that at a later point Guillaume Martres (or another Dotty committer) said that they had given up unifying the two in the implementation.

How is this related to the subject at hand? (or did you intend to refer to a SO post)?

The intention was to update a possibly out-of-date highly viewed question with potentially incorrect answer (as it uses System.nanoTime). Although it was not strictly related to Scala 3. I have removed it.