blocks|key|1961058|text|不是答案，而是在REPL中隐式使用的一些线索。编译器不认为类型是相同的。推断的类型更具体：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1961059|//+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]|code-block|syntax|javascript|1961060|检查类型别名是否正确：|1961061|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|1961062|类型不同：|1961063|implicitly[Soc+=:=+Inferred]+//+error|1961064|您的类型是推断类型的超类型：|1961065|implicitly[Inferred+<:<+Soc]+//+ok
implicitly[Soc+<:<+Inferred]+//+error|1961066|因此，根据编译器的说法，它提出了一个更具体的类型-这将是正确的做法。请注意，可以像这样重新创建用例：|1961067|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|1961068|所以我想知道我们是否可以创建一个是DI_SOC而不是DI的类，这将说明DI和DI_SOC是不同的类型，并且您的类型不是最小上限。|offset|length|style|CODE|1961069|好的，在走出电脑一小段时间后，再试一次。下面是一个不是DI的DI_SOC类|1961070|class+A+extends+N+with+C[N]
implicitly[A+<:<+DI_SOC]+//+ok
implicitly[A+<:<+DI]+++++//+error|1961071|适用于原始用例：|1961072|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|1961073|因此，Soc和Inferred的类型是不同的，Ax证明了Number+with+Comparable[_+>:+Double+with+Integer+<:+Number]不是最小上界。|1961074|换句话说，在Double+with+Integer+<:+?+<:+Number之间有一些空间，但在Double+with+Integer+<:+?+<:+Number+with+Comparable[_+>:+Double+with+Integer+<:+Number]之间没有太多空间|1961075|entityMap^0|0|0|0|0|0|0|0|0|0|0|H|6|Q|2|Z|2|12|6|0|R|2|U|6|0|0|0|0|3|3|7|8|N|2|S|1M|0|6|Y|1E|2E|0^^$0|@$1|2|3|4|5|6|7|1G|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|1H|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|1I|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|1J|8|@]|9|@]|A|$E|F]]|$1|K|3|L|5|6|7|1K|8|@]|9|@]|A|$]]|$1|M|3|N|5|D|7|1L|8|@]|9|@]|A|$E|F]]|$1|O|3|P|5|6|7|1M|8|@]|9|@]|A|$]]|$1|Q|3|R|5|D|7|1N|8|@]|9|@]|A|$E|F]]|$1|S|3|T|5|6|7|1O|8|@]|9|@]|A|$]]|$1|U|3|V|5|D|7|1P|8|@]|9|@]|A|$E|F]]|$1|W|3|X|5|6|7|1Q|8|@$Y|1R|Z|1S|10|11]|$Y|1T|Z|1U|10|11]|$Y|1V|Z|1W|10|11]|$Y|1X|Z|1Y|10|11]]|9|@]|A|$]]|$1|12|3|13|5|6|7|1Z|8|@$Y|20|Z|21|10|11]|$Y|22|Z|23|10|11]]|9|@]|A|$]]|$1|14|3|15|5|D|7|24|8|@]|9|@]|A|$E|F]]|$1|16|3|17|5|6|7|25|8|@]|9|@]|A|$]]|$1|18|3|19|5|D|7|26|8|@]|9|@]|A|$E|F]]|$1|1A|3|1B|5|6|7|27|8|@$Y|28|Z|29|10|11]|$Y|2A|Z|2B|10|11]|$Y|2C|Z|2D|10|11]|$Y|2E|Z|2F|10|11]]|9|@]|A|$]]|$1|1C|3|1D|5|6|7|2G|8|@$Y|2H|Z|2I|10|11]|$Y|2J|Z|2K|10|11]]|9|@]|A|$]]|$1|1E|3|-4|5|6|7|2L|8|@]|9|@]|A|$]]]|1F|$]]

Not an answer but some clues using implicitly in the REPL. The compiler doesn't think the types are the same. The inferred type is more specific:

<pre><code>// 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[
 _ &gt;: Dx with Ix &lt;: Number with Comparable[_ &gt;: Dx with Ix &lt;: Number]]

// your type:
type Soc = Number with Comparable[_ &gt;: Dx with Ix &lt;: Number]
</code></pre>

Checking I did the type aliases right:

<pre><code>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
</code></pre>

Types are not the same:

<pre><code>implicitly[Soc =:= Inferred] // error
</code></pre>

Your type is a super type of the inferred type:

<pre><code>implicitly[Inferred &lt;:&lt; Soc] // ok
implicitly[Soc &lt;:&lt; Inferred] // error
</code></pre>

So according to the compiler, it came up with a more specific type - which would be the right thing to do. Note that the use case can be re-created like this:

<pre><code>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[_ &gt;: D with I &lt;: N with C[_ &gt;: D with I &lt;: N]]
// DI is like the type inferred

type DI_SOC = N with C[_ &gt;: D with I &lt;: 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 &lt;:&lt; DI_SOC] // DI_SOC super type of DI
implicitly[DI_SOC &lt;:&lt; DI] // error
</code></pre>

So I wonder if we can craft a class that is a <code>DI_SOC</code> but not a <code>DI</code>, which would illustrate <code>DI</code> and <code>DI_SOC</code> are not the same types and your type is not the least upper bound. 

Ok, after stepping out for the computer for a bit and then trying again. Here is a class that is a <code>DI_SOC</code> but not a <code>DI</code>:

<pre><code>class A extends N with C[N]
implicitly[A &lt;:&lt; DI_SOC] // ok
implicitly[A &lt;:&lt; DI] // error
</code></pre>

Applied to the original use case:

<pre><code>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 &lt;:&lt; Soc] // ok
implicitly[Ax &lt;:&lt; Inferred] // error
</code></pre>

Therefore, the types <code>Soc</code> and <code>Inferred</code> are not the same and <code>Ax</code> proves that <code>Number with Comparable[_ &gt;: Double with Integer &lt;: Number]</code> is not the least upper bound...

In other words, there is some room between <code>Double with Integer &lt;: ? &lt;: Number</code> but not much between <code>Double with Integer &lt;: ? &lt;: Number with Comparable[_ &gt;: Double with Integer &lt;: Number]</code>

Consider this code:

<pre><code>val foo = if(true) 
 new java.lang.Double(4) 
 else
 new java.lang.Integer(4)
</code></pre>

The inferred type for <code>foo</code> is:

<pre><code>Number with Comparable[_ &gt;: Double with Integer &lt;: Number with 
 Comparable[_ &gt;: Double with Integer &lt;: Number]]
</code></pre>

So basically the compiler loops on the bounds and aborts after the third recursion.

Why isn't the following enough?

<pre><code>Number with Comparable[_ &gt;: Double with Integer &lt;: Number]
</code></pre>

Why is the least upper bound of java.lang.Integer and java.lang.Double inferred as a acyclic type?

编译器

考虑下面的代码：val foo = if(true)             new java.lang.Double(4)           else            new java.lang.Integer(4)foo的推断类型为：Number with Comparable[_ >: Double wi...

问为什么java.lang.Integer和java.lang.Double的最小上界被推断为非循环类型？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为什么java.lang.Integer和java.lang.Double的最小上界被推断为非循环类型？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为什么java.lang.Integer和java.lang.Double的最小上界被推断为非循环类型？
EN