Imported From: https://issues.scala-lang.org/browse/SI-3443?orig=1
Reporter: @harrah

@odersky said:
There was some tightening of the rules between 2.7 and 2.8. I am pretty sure the new rules are a better approximation to safety than the old ones. To re-open the ticket, I'd need a one-by-one argument why this code should be accepted. Note that

A # B is now equivalent to (x.B forSome x: A)

@harrah said:
Ok, but are they supposed to be equivalent all of the time?

Using TFn1 from above:

trait TFn1[I, O] {
  type app[i <: I] <: O
}

B and B2 below should be equivalent, right?

trait Test {
  type a
  type b
  type f = TFn1[a, b]

   // compiles,
   //  browsing the tree shows TypeRefs only
  type B = f#app[a]

   // should be equivalent to B?
   //  does not compile though,
   //  tree shows Existential as expected
  type B2 = x.app[a] forSome { val x: f }
}

The compile error related to B2 is the same as in the original report:

type arguments [Test.this.a] do not conform to type app's type parameter bounds [i <: I]
        type B = x.app[a] forSome { val x: f }
                          ^

@adriaanm said:
(In r24029) introduce NullaryMethodType to disambiguate PolyType

motivation:
given def foo[T]: (T, T) and type Foo[T] = (T, T),

foo.info and TypeRef(_, Foo, Nil).normalize are both PolyType(List(T), Pair[T, T])

uncurry has been relying on an ugly hack to distinguish these cases based on ad-hoc kind inference
without this distinction, the type alias's info (a type function) would be transformed to PolyType(List(T), MethodType(Nil, Pair[T, T]))

anonymous type functions are being used more often (see #2741, #4017, #4079, #3443, #3106), which makes a proper treatment of PolyTypes more pressing

change to type representation:
PolyType(Nil, tp) -> NullaryMethodType(tp)
PolyType(tps, tp) -> PolyType(tps, NullaryMethodType(tp)) (if the polytype denoted a polymorphic nullary method)

PolyType(Nil, tp) is now invalid

the kind of a PolyType is * iff its resulttype is a NullaryMethodType or a MethodType (i.e., it's a polymorphic value)
in all other cases a PolyType now denotes a type constructor

NullaryMethodType is eliminated during uncurry

pickling:
for backwards compatibility, a NullaryMethodType(tp) is still pickled as a PolyType(Nil, tp),
unpickling rewrites pre-2.9-pickled PolyTypes according to the expected kind of the unpickled type (similar to what we used to do in uncurry)
a pickled PolyType(Nil, restpe) is unpickled to NullaryMethodType(restpe)
a pickled PolyType(tps, restpe) is unpickled to PolyType(tps, NullaryMethodType(restpe)) when the type is expected to have kind *

the rewrite probably isn't complete, but was validated by compiling against the old scalacheck jar (which has plenty of polymorphic nullary methods)
nevertheless, this commit includes a new scalacheck jar

summary of the refactoring:

• PolyType(List(), tp) or PolyType(Nil, tp) or PolyType(parms, tp) if params.isEmpty ==> NullaryMethodType(tp)

• whenever there was a case PolyType(tps, tp) (irrespective of tps isEmpty), now need to consider the
  case PolyType(tps, NullaryMethodType(tp)); just add a case NullaryMethodType(tp), since usually:

  • there already is a PolyType case that recurses on the result type,
  • the polytype case applied to empty and non-empty type parameter lists alike

• tp.resultType, where tp was assumed to be a PolyType that represents a polymorphic nullary method type
  before, tp == PolyType(tps, res), now tp == PolyType(tps, NullaryMethodType(res))

• got bitten again (last time was dependent-method types refactoring) by a TypeMap not being the identity when dropNonConstraintAnnotations is true (despite having an identity apply method). Since asSeenFrom is skipped when isTrivial, the annotations aren't dropped. The cps plugin relies on asSeenFrom dropping these annotations for trivial types though. Therefore, NullaryMethodType pretends to never be trivial. Better fix(?) in AsSeenFromMap: if(tp.isTrivial) dropNonContraintAnnotations(tp) else ...

TODO: scalap and eclipse

review by odersky, rytz