Add blogpost: Tribulations of CanBuildFrom

[julienrf]

The plan is to publish the blogpost next Monday.

[julienrf]

This is how the diagram looks like locally:

[milessabin]

Perhaps I'm being picky, but why use "Kind polymorphism" as the heading of a section which doesn't further discuss kind polymorphism (either as implemented in Typelevel Scala or elsewhere) and which illustrates without comment exactly the sort of arity-specific boilerplate which kind polymorphism in some form could eliminate?

[julienrf]

@milessabin Actually I think “Kind polymorphism” is probably not an appropriate heading.

Also, unfortunately, in practice the way kind-polymorphism is implemented in Typelevel Scala does not really make things simpler:

trait MapDef[A, B, CC <: AnyKind] {
  type In
  type Out
  def map(in: In)(f: A => B): Out
}

trait IterableOps[A, CC <: AnyKind] {
  def map[B](f: A => B)(implicit mapDef: MapDef[A, B, CC] { type In = this.type }): mapDef.Out = mapDef.map(this)(f)
}

trait Map[K, V] { … }

object Map {
  implicit def mapDef[K, V, L, W]: MapDef[(K, V), (L, W), Map] { type In = Map[K, V]; type Out = Map[L, W] } = …
}

[milessabin]

@julienrf I think changing the heading is the best bet.

Yes, the minimal kind polymorphism in TLS isn't up to this job, but I think it's worth exploring what can be done with something quite that minimal, and I think it would be worth exploring more sophisticated implementations.

[szeiger]

You may want to point out that this new design required improvements to type inference which are only available in 2.12.

[szeiger]

but we lose the ability to abstract over arbitrary map implementations in a unified way

[julienrf]

I think this point is not very important from the point of view of users. That’s more related to our internal implementation.

[szeiger]

You may also want to mention breakOut as a separate usecase.

[julienrf]

About breakOut: this is an escape hatch in case the implicit resolution of CBF does not give the expected type. So, it’s not really a “feature” but a workaround related to the way CBF works.

[szeiger]

I disagree. breakOut is a feature, not a workaround. It allows you to build whatever target collection type you need without copying from an intermediate collection. Can we replace all current use cases by Views? I checked for some obvious cases (like groupBy) where you would return some type that wraps That (instead of returning That directly) but they don't support CanBuildFrom. Are there others that do? These would be the cases that can't work with Views.

[julienrf]

OK, I added a section about breakOut. WDYT?

[szeiger]

How about "This requires the target type to be known, in this case via an explicit type ascription"?

[heathermiller]

LGTM :) Merci @julienrf and thank you @milessabin and @szeiger for your reviews! :)