abstract casting

[andyli]

While trying to write a more advanced EitherType, I faced the following issue:

abstract E2<T1,T2>(Dynamic)
from T1 from T2 from E2<T2,T1>
to T1 to T2 to E2<T2,T1>
{}

class Test {
    function main():Void {
        var v1:E2<Int,String> = 1;
        var v2:E2<String,Int> = 2;
        v1 = v2; //E2<String, Int> should be E2<Int, String>
    }
}

Try to workaround, faced another issue:

abstract E2<T1,T2>(Dynamic)
from T1 from T2
to T1 to T2
{
    // note that it compiles fine if not inline
    @:from inline static function _from2<_T1:E2<T1,T2>, _T2:E2<T1,T2>>(e:E2<_T1,_T2>):E2<T1,T2> {
        return untyped e;
    }
}
class Test {
    function main():Void {
        var v1:E2<Int,String> = 1;
        var v2:E2<String,Int> = 2;
        v1 = v2; //e : E2<Unknown<0>, Unknown<1>> -> E2<E2.T1, E2.T2> should be E2<String, Int> -> E2<Int, String>
    }
}

[nadako]

There's some problem with nested EitherTypes indeed. I just got one while working hxnodejs:

import haxe.EitherType;

typedef T = EitherType<Int, Array<EitherType<Int,String>>>;

class Main {
    static function main() {
        var a:T = [1]; // Works

        var a:T = [""]; // Array<Int> should be T
                        // Array<Int> should be haxe.EitherType<Int, Array<haxe.EitherType<Int, String>>>
    }
}

[Simn]

That's an interesting case, but I think we can support it easily.

[Simn]

As a side-note @elsassph: The first E2 declaration triggers an inheritance loop message in FD.

[elsassph]

@Simn this might be fixed in the dev builds.

[Simn]

There is an obsolete check in the compiler which allows you to use T1 and T2 in that static function. I'll remove that so your second example becomes invalid, but works if you add these type parameters to the method.