1

Ich habe versucht, einen Typalias für den abhängigen Typ _ >: a.type zu erstellen.Warum verbietet Scala-Compiler die Deklaration eines Wildcard-Typs als Super-Typ eines Typparameters

Der Scala-Compiler einen Fehler meldet, die ich nicht verstehe:

scala> def foo[A](a: A) = { 
    | type F = Function1[_ >: a.type, Unit] 
    | } 
<console>:12: error: type mismatch; 
found : a.type (with underlying type A) 
required: AnyRef 
Note that A is unbounded, which means AnyRef is not a known parent. 
Such types can participate in value classes, but instances 
cannot appear in singleton types or in reference comparisons. 
     type F = Function1[_ >: a.type, Unit] 
           ^

Wenn ich a: A zu a: A with AnyRef ersetzen, es funktioniert:

scala> def foo[A](a: A with AnyRef) = { 
    | type F = Function1[_ >: a.type, Unit] 
    | } 
foo: [A](a: A with AnyRef)Unit 

Warum? Was ist der Zweck der Beschränkung?

Antwort

5

See: http://docs.scala-lang.org/sips/pending/42.type.html

Alle vs AnyRef

Derzeit gibt es eine Möglichkeit Singleton Arten in bestimmten Kontexten zu verwenden, aber nur auf Kennungen, die auf eine Konstante, die AnyRef entspricht. Diese Einschränkung ist darauf zurückzuführen, dass Any über keine eq-Methode verfügt, die für die Singleton-Typgleichheitsüberprüfung und die Mustererkennung verwendet wird https://github.com/scala/scala/pull/3558. Dies wurde auf der Mailing-Liste here und here diskutiert, und es gibt eine Einwilligung, dass dies getan werden muss.

+0

Ich verstehe immer noch nicht, warum es wirkt _>: a.type. Ich dachte, ein existentieller Typ wie _>: a.type würde nie an der Typgleichheitsprüfung beteiligt sein. –

+0

Ich gehe davon aus, dass der Kontext bei der Anwendung der Schutzmaßnahme nicht berücksichtigt wird; Lasst uns hoffen, dass einer der Scala Sprachgurus klären wird. – devkat