diff options
author | Martin Odersky <odersky@gmail.com> | 2017-03-04 17:27:10 +0100 |
---|---|---|
committer | Martin Odersky <odersky@gmail.com> | 2017-03-04 18:28:21 +0100 |
commit | 353a4d9f17b91d09dea3c9090c7a21e267372abe (patch) | |
tree | 08e1541da2f277c17da167ee6b9758a3f08e5f90 /compiler/src/dotty/tools/dotc/core/TypeComparer.scala | |
parent | 06d3f7aefa620ce006008955203d7f8f8dc7b605 (diff) | |
download | dotty-353a4d9f17b91d09dea3c9090c7a21e267372abe.tar.gz dotty-353a4d9f17b91d09dea3c9090c7a21e267372abe.tar.bz2 dotty-353a4d9f17b91d09dea3c9090c7a21e267372abe.zip |
Drop named type parameters in classes
Drop the [type T] syntax, and what's associated to make it work.
Motivation: It's an alternative way of doing things for which there seems
to be little need. The implementation was provisional and bitrotted during
the various iterations to introduce higher-kinded types. So in the end the
complxity-cost for language and compiler was not worth the added benefit
that [type T] parameters provide.
Noe that we still accept _named arguments_ [A = T] in expressions; these are useful
for specifying some parameters and letting others be inferred.
Diffstat (limited to 'compiler/src/dotty/tools/dotc/core/TypeComparer.scala')
-rw-r--r-- | compiler/src/dotty/tools/dotc/core/TypeComparer.scala | 14 |
1 files changed, 1 insertions, 13 deletions
diff --git a/compiler/src/dotty/tools/dotc/core/TypeComparer.scala b/compiler/src/dotty/tools/dotc/core/TypeComparer.scala index fca111702..b97dfe684 100644 --- a/compiler/src/dotty/tools/dotc/core/TypeComparer.scala +++ b/compiler/src/dotty/tools/dotc/core/TypeComparer.scala @@ -1264,22 +1264,10 @@ class TypeComparer(initctx: Context) extends DotClass with ConstraintHandling { } } - /** `op(tp1, tp2)` unless `tp1` and `tp2` are type-constructors with at least - * some unnamed type parameters. + /** `op(tp1, tp2)` unless `tp1` and `tp2` are type-constructors. * In the latter case, combine `tp1` and `tp2` under a type lambda like this: * * [X1, ..., Xn] -> op(tp1[X1, ..., Xn], tp2[X1, ..., Xn]) - * - * Note: There is a tension between named and positional parameters here, which - * is impossible to resolve completely. Say you have - * - * C[type T], D[type U] - * - * Then do you expand `C & D` to `[T] -> C[T] & D[T]` or not? Under the named - * type parameter interpretation, this would be wrong whereas under the traditional - * higher-kinded interpretation this would be required. The problem arises from - * allowing both interpretations. A possible remedy is to be somehow stricter - * in where we allow which interpretation. */ private def liftIfHK(tp1: Type, tp2: Type, op: (Type, Type) => Type, original: (Type, Type) => Type) = { val tparams1 = tp1.typeParams |