If we get rid of the `c` param, won't we have to register the traversables
like this?

```scala
  .forTraversableSubclass[Any, Queue[Any]]()
  .forTraversableSubclass[Any, List[Any]]()
```

I was keeping the `c` param to help the type inferencing out and to
properly bind `C` and `T`. I futzed with it for a good bit and ended up
with what's in the pull request. My scala-fu may be missing something,
though. Maybe you could try out the code from my fork some time and try to
get it to work with `CanBuildFrom[Nothing, T, C]`?


On Tue, May 28, 2013 at 2:45 PM, P. Oscar Boykin
<notifications@github.com>wrote:

> In chill-scala/src/main/scala/com/twitter/chill/RichKryo.scala:
>
> > @@ -77,9 +76,9 @@ class RichKryo(k: Kryo) {
> >      k
> >    }
> >
> > -  def forTraversableSubclass[T, C <: Traversable[T]](b: Builder[T,C], isImmutable: Boolean = true)
> > -    (implicit mf: ClassManifest[C]): Kryo = {
> > -    k.addDefaultSerializer(mf.erasure, new TraversableSerializer(b, isImmutable))
> > +  def forTraversableSubclass[T, C <: Traversable[T]](c: C with Traversable[T], isImmutable: Boolean = true)
> > +    (implicit mf: ClassManifest[C], cbf: CanBuildFrom[C, T, C]): Kryo = {
>
> But we never use the From parameter. It seems strange that we actually
> throw c away. I think this code would work just as well with:
>
> def forTraversableSubclass[T, C](isImmutable: Boolean = true)(implicit mf: ClassManifest[C], cbf: CanBuildFrom[Nothing, T, C]): Kryo = {
>
> Would that cause any issue since we only use the def apply(): Builder[T,
> C] method?
>
> —
> Reply to this email directly or view it on GitHub<https://github.com/twitter/chill/pull/57/files#r4423564>
> .
>