List("ab").toSet.head.head won't compile

[scabug]

scala> List("ab").toSet.head.head
<console>:8: error: value head is not a member of type parameter B
              List("ab").toSet.head.head

[scabug]

Imported From: https://issues.scala-lang.org/browse/SI-7743?orig=1
Reporter: Sagie Davidovich (sagie.d)
Affected Versions: 2.10.2

[scabug]

Tomer Gabel (holograph) said:
Can be worked around with:

scala> val a=List("ab").toSet.head
a: String = ab

scala> a.head
res2: Char = a

[scabug]

@som-snytt said:
scala> List("ab").to[Set].head.head
res1: Char = a

[scabug]

Tomer Gabel (holograph) said:
A.P: Which Scala version do you use? In my case:

arilou:incubator-curator tomer$ scala -version
Scala code runner version 2.10.2 -- Copyright 2002-2013, LAMP/EPFL

[scabug]

Tomer Gabel (holograph) said:
Also, your code sample is different :-) (toSet -> to[Set])

[scabug]

@SethTisue said:
I think this is just another version of this old chestnut: http://stackoverflow.com/questions/5544536/type-inference-on-set-failing

the least intrusive workaround IMO is List("ab").toSet[String].head.head

[scabug]

Christopher Vogt (cvogt) said:
Another workaround: {code}List("ab").to[Set].head.head{code}

[joroKr21]

Interesting comparison with typelevel scala:

• 2.12.4-bin-typelevel-4

scala> List("ab").toSet.head.head
<console>:12: error: value head is not a member of type parameter B
       List("ab").toSet.head.head

scala> List("ab").toSet.map(_.length)
res4: scala.collection.immutable.Set[Int] = Set(2)

• 2.12.6

scala> List("ab").toSet.head.head
<console>:12: error: value head is not a member of type parameter B
       List("ab").toSet.head.head
                             ^

scala> List("ab").toSet.map(_.length)
<console>:12: error: missing parameter type for expanded function ((x$1: <error>) => x$1.length)
       List("ab").toSet.map(_.length)

@milessabin any idea what causes the second example to compile on typelevel scala? Might be worth porting over.

[milessabin]

@joroKr21 I'm pretty sure it's down to some experimental bounds propagation work that @paulp did (scala/scala@dc1bbb9) which turned out to be important to the literal types PR.

I'm not quite sure where it ended up. I rolled it into the the unconditionalizing of literal types (scala/scala@beb2dac), then it might have been removed, or at least simplified by @adriaanm (scala/scala@272d17b).

How does it look in 2.13.0-M5?

[joroKr21]

• 2.13.0-20180923-122040-2e82444 (currently latest)

scala> List("ab").toSet.head.head
                             ^
       error: value head is not a member of type parameter B

scala> List("ab").toSet.map(_.length)
                            ^
       error: missing parameter type for expanded function ((x$1: <error>) => x$1.length)

But looking at the tests added in scala/scala@272d17b this appears to be intentional.

[milessabin]

I think the tests might be documenting the status quo, however. It would be good to know what breakage was actually motivating sticking with that. @adriaanm?

It might be worth reviving this as a separate PR. I'd certainly consider it for the next TLS releases.

[adriaanm]

There's a second test to illustrate the problem with adding the bounds from the start. You end up over-constraining the type variable. Sometimes it's important that we know it's undetermined (by the environment), so that we use Wildcard as the expected type, rather than the bound that's on the type parameter. Typing without expected type may result in a sharper type than typing under, say, AnyVal.