Почему наименее верхняя граница java.lang.Integer и java.lang.Double выводится как ациклический тип? - PullRequest
Новая
       40

Почему наименее верхняя граница java.lang.Integer и java.lang.Double выводится как ациклический тип?

16 голосов
/ 13 ноября 2011

Рассмотрим этот код: 

val foo = if(true) 
            new java.lang.Double(4) 
          else
            new java.lang.Integer(4)

Предполагаемый тип для foo: 

Number with Comparable[_ >: Double with Integer <: Number with 
  Comparable[_ >: Double with Integer <: Number]]

Таким образом, в основном, компилятор выполняет циклы по границам и прерывается после третьей рекурсии.1008 *

Почему недостаточно следующего? 

Number with Comparable[_ >: Double with Integer <: Number]

1 Ответ

8 голосов
/ 13 ноября 2011

Не ответ, но некоторые подсказки, использующие неявно в REPL.Компилятор не думает, что типы одинаковы.Предполагаемый тип более конкретен: 

// some type aliases to make reading easier
type Dx = java.lang.Double
type Ix = java.lang.Integer

// the type the compiler came up with:
type Inferred = Number with Comparable[
  _ >: Dx with Ix <: Number with Comparable[_ >: Dx with Ix <: Number]]

// your type:
type Soc = Number with Comparable[_ >: Dx with Ix <: Number]

Проверка правильности псевдонимов типов: 

val d = new java.lang.Double(4)
val i = new java.lang.Integer(4)
val foo: Soc = if (true) d else i
// foo: Soc = 4.0
val foo: Inferred = if (true) d else i
// foo: Inferred = 4.0

Типы не совпадают: 

implicitly[Soc =:= Inferred] // error

Ваш типявляется супертипом выведенного типа: 

implicitly[Inferred <:< Soc] // ok
implicitly[Soc <:< Inferred] // error

Итак, в соответствии с компилятором, он придумал более конкретный тип - что было бы правильно.Обратите внимание, что сценарий использования может быть воссоздан следующим образом: 

class N                     // like java.lang.Number

trait C[T]                  // like Comparable

class I extends N with C[I] // like java.lang.Integer
class D extends N with C[D] // like java.lang.Double

type DI = N with C[_ >: D with I <: N with C[_ >: D with I <: N]]
// DI is like the type inferred

type DI_SOC = N with C[_ >: D with I <: N] // your type

val foo: DI = if (true) new D else new I     // ok
val foo: DI_SOC = if (true) new D else new I // ok

implicitly[DI =:= DI_SOC] // error
implicitly[DI <:< DI_SOC] // DI_SOC super type of DI
implicitly[DI_SOC <:< DI] // error

Поэтому мне интересно, сможем ли мы создать класс, который является DI_SOC, но не DI, который иллюстрировал бы DIи DI_SOC не являются одними и теми же типами, и ваш тип не является наименьшей верхней границей.

Хорошо, после того, как вы ненадолго вышли за компьютер, а затем попытались снова.Вот класс, который является DI_SOC, но не DI: 

class A extends N with C[N]
implicitly[A <:< DI_SOC] // ok
implicitly[A <:< DI]     // error

Применительно к исходному сценарию использования: 

class Ax extends Number with Comparable[Number] {
  def doubleValue() = 0d
  def floatValue() = 0f
  def intValue() = 0
  def longValue() = 0L
  def compareTo(n: Number) = 0
}

implicitly[Ax <:< Soc]      // ok
implicitly[Ax <:< Inferred] // error

Следовательно, типы Soc иInferred являются не одинаковыми и Ax доказывает, что Number with Comparable[_ >: Double with Integer <: Number] является не наименьшей верхней границей ...

Другими словами, есть некоторыекомната между Double with Integer <: ? <: Number, но не очень между Double with Integer <: ? <: Number with Comparable[_ >: Double with Integer <: Number]

...