Tweak and implement weak conformance replacement

[odersky]

No description provided.

[SethTisue]

     Array(b, 33, 5.5)      : Array[Double] // b is an inline val
     Array(f(), 33, 5.5)    : Array[AnyVal] // f() is not a constant
     Array(5, 11L)          : Array[Long]
     Array(5, 11L, 5.5)     : Array[AnyVal] // Long and Double found
     Array(1.0f, 2)         : Array[Float]
     Array(1.0f, 1234567890): Array[AnyVal] // loss of precision
     Array(b, 33, 'a')      : Array[Char]
     Array(5.toByte, 11)    : Array[Byte]

I know there is rhyme and reason underlying this list of examples, but it's extraordinarily difficult for the casual eye to discern. I worry that anyone looking at this list will find it quite strange and off-putting

in cases where isn't obvious what the inferred type should be, can we make it a compile error unless a type parameter is explicitly supplied? is that a design path that's been explored?

[dwijnand]

Is this revisiting #2451?

[smarter]

The context is #5358

[odersky]

in cases where isn't obvious what the inferred type should be, can we make it a compile error unless a type parameter is explicitly supplied? is that a design path that's been explored?

The issue we are addressing here is that we want to follow intuition where it is obvious. Mixing elements of different numeric types gives an AnyVal, as usual. Except that if you write

Array(2.0, 3.0, 0, 4.0)

you really want it to mean Array[Double]. Everything else is just silly. Note this also aligns with how int constants are treated elsewhere in Java and Scala. E.g.

val x: Byte = 33

is accepted, since 33 is implicitly converted to a Byte. Again, everything else would just be needlessly pedantic.

[sjrd]

Why was this changed back from AnyVal to Char? Didn't we agree that Chars should never be considered as numeric types for the purpose of harmonization?

[odersky]

I thought we agreed that a Char literal should not be converted to another numeric type, same as a Float or a Double is not converted.

But this case is different: It's an Int constant that is converted to a Char type. Same as it could be converted to a Short or Byte type. I agree that Char feels strange, but the fact is it is a member of Java's numeric hierarchy, so I believe it's better to be consistent.

We do allow:

scala> val c: Char = 65
c: Char = A

So it's inconsistent to not also allow this in harmonization.

[odersky]

I see now that Char is not in the spec.

if all the other expressions have the same numeric type T (which can be one of Byte, Short, Int, Long, Float, Double)

Somehow I overlooked this before. So we'd either have to put Char back in the spec, or change the implementation to not convert to Char. At this stage it's all the same for me. Consistency with assignment is nice to have but if people feel strongly agaist I won't argue any longer.

[sjrd]

What about Bytes and Shorts? (and Chars, if they are considered numeric after all?)

[odersky]

These are covered under c.convertTo(cls.typeRef) != null

[ShaneDelmore]

Array(2.0, 3.0, 0, 4.0)

you really want it to mean Array[Double]. Everything else is just silly.

If I wrote this it would be a mistake. The compiler would infer what I meant, and every future reader would need to infer what I mean, but what I really want is for an error to remind me to either add .0, or just specify the type so nobody has to play computer in their head and infer the type when it is so trivial to just correct the oversight.

I understand this may not be what others want, just offering another perspective.