Type inference fails for singleton objects

[scabug]

The following fails with a type mismatch:

object Foo
val f: Option[Foo.type] = Some(Foo)

but succeeds with extra type annotation:

val f: Option[Foo.type] = Some[Foo.type](Foo)

This is annoying and I wish it were different :) Especially for the case with multiple type parameters, all of which can be inferred except for the singleton...

[scabug]

Imported From: https://issues.scala-lang.org/browse/SI-1208?orig=1
Reporter: Aaron Harnly (aaronharnly)

[scabug]

Aaron Harnly (aaronharnly) said:
Forgot to mention, this is in 2.7.1 and in trunk as of r15611.

[scabug]

@odersky said:
This has come up several times before. Changing this begavior would break lots of things, so I don't see it happening.

[scabug]

Geoffrey Alan Washburn (washburn) said:
I think this needs to be fixed eventually because it violates the principle that the inference algorithm should infer the most precise type possible.

[scabug]

@odersky said:
I refer to the spec:

The type of a designator is the type $$T$$ of the entity it refers to, with the
following exception: The type of a path (\sref{sec:paths}) $$p$$ which
occurs in a context where a stable type (\sref{sec:singleton-types}) is required is the
singleton type \lstinline@$$p$$.type@.

I invite everyone to change this rule, and observe what breaks!

[scabug]

Lauri Alanko (lealanko) said:
Inferring a more specific type than currently would break at least programs where that type is used in a non-positive position, in particular vars and type arguments to non-covariant type parameters.

Personally, I think it's a bad idea to infer a type into a non-positive position from a positive occurrence (i.e. the type of a value), and wouldn't mind requiring explicit type annotations/arguments for such situations, if that would make inference into positive positions work better. Granted, this would make local vars less practical, but personally I don't see much reason to make imperative programming too easy. :)

[scabug]

@odersky said:
I think discussions like this are fine, when done on the mailing list, but they should not be tickets. I am utterly overloaded already with fixing real bugs. Discussion about language design are better done using mailing lists and/or SIPS.

[scabug]

@odersky said:
Milestone next_feature deleted

[scabug]

@paulp said:
Reopening for lulz.

[scabug]

@paulp said:
(In r23622) "I invite everyone to change this rule, and observe what breaks!"

This much beloved comment from #1208 has been on my radar for two
years. The worm has turned. Closes #1208. The inferred type of an
object is now Foo.type instead of "object Foo". What once was this:

scala> val x: Map[Int, Singleton] = Map(1 -> None)
:5: error: type mismatch;
found : (Int, object None)
required: (Int, Singleton)

Now exudes a pleasing aura of workingness:

scala> val x: Map[Int, Singleton] = Map(1 -> None)
x: Map[Int,Singleton] = Map(1 -> None)

No review.

[scabug]

@okomok said:
Does it mean "the types of modules are inferred"?
This behavior is not specified in the SLS?