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

Closed
shamanas opened this Issue Sep 21, 2014 · 6 comments

Projects

None yet

2 participants

@shamanas
Collaborator

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()
@shamanas shamanas added the Discussion label Sep 21, 2014
@shamanas
Collaborator

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

@fasterthanlime
Collaborator

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.

@shamanas
Collaborator

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)

@shamanas
Collaborator

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

@shamanas
Collaborator

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 fasterthanlime added a commit that closed this issue Jul 9, 2015
@fasterthanlime fasterthanlime Closes #827 85da9b3
@fasterthanlime
Collaborator

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

@fasterthanlime fasterthanlime modified the milestone: 0.9.10 Jul 10, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment