Should the common root of a cover and class type be Object?

[alexnask]

Rock currently uses findCommonRoot to determine the type of array literals and match expressions.
My goal is to use it in variety of places, pretty much any place where rock must determine a single type from multiple ones.
Current places I am thinking of adding it: built-in (/ C fall-through) binary operators (currently the left hand expressions' type is used ... bleh) and generic type inference (where the first type infered is currently used).

However, right now, every two basic types have a common root: Object.
I feel like this has always been a weakness of the ooc type-system, because code that looks an theoretically should be correct leads to both C compile (scalar conversion) and runtime errors.

I suggest that at least the compiler should start to separate the two making cover types and Object incompatible, at least when referring to common roots.

What this means: nothing changes with function scoring, casting etc (at least at the moment)

Annoying stuff like below stop happening:

// This currently infers to Object[], crashes at C compile time
// After change: Incompatible types Float, String (covers vs. class)
a := [1, 2.0f, "String", 'v']

// a is now an Object (according to rock)
a := match 'a' {
    case 'a' => 0
    case => "Hello World!"
}

// Kaboom!
a class name println()

[alexnask]

Alternatively, covers from C types could stop inheriting Object (is that doable actually?)

[fasterthanlime]

Alternatively, covers from C types could stop inheriting Object (is that doable actually?)

I actually tried to fix that recently - last time I touched rock. It's most likely doable, but not trivially. The metaclass business is still a mess.

[alexnask]

The thing is there is still an issue with compound covers, as they are still value types and casting them to Object is considered legal (ofc, since theytheoretically inherit Object)

[alexnask]

Another option would be automatic boxing/unboxing of value types into Cell, like the people @cogneco have proposed

[alexnask]

Imho there should definitively be a system to separate value covers (cover from scalar types and compound covers) from reference covers (cover from pointer type).
There would be issues covering from typedef'ed C pointer types though.

[fasterthanlime]

Added your test case @Shamanas, and it does fail with a compile error. Tell me if I missed something.