Typing issue with abstracts + op overloading

[waneck]

The following code:

import neko.Lib;
abstract Int64(Int64_t)
{
    inline private function new(i)
    {
        this = i;
    }

    inline public static function make(a:Int, b:Int):Int64
    {
        return __make(a,b);
    }

    @:op(A*B) inline public function mul_i64(a:Int64):Int64
    {
        return __mul(this,a);
    }

    static var __make:Dynamic->Dynamic->Int64 = null;
    static var __mul:Dynamic->Dynamic->Int64 = null;
}

abstract Int64_t(Dynamic) {}

Main.hx:

class Main
{
    static function main()
    {
        var a = Int64.make(0,0xFFAAFF),
                b = Int64.make(0,0xAAFFAA);
        var c = a * b;
        $type(c);
        $type(a*b);
    }
}

Fails to compile with the following output:

Main.hx:8: characters 10-11 : Int64 should be Int
Main.hx:8: characters 14-15 : Int64 should be Int
Main.hx:9: characters 8-9 : Warning : Int
Main.hx:10: characters 8-9 : Int64 should be Int
Main.hx:10: characters 10-11 : Int64 should be Int
Main.hx:10: characters 8-11 : Warning : Int

[waneck]

If instead of abstract Int64_t(Dynamic), a typedef Int64_t = Dynamic is done, the code compiles, but then does some strange casts to String (if a @:to function to String is defined)

[waneck]

Nevermind the above comment, the cast was due to a toString() with a Dynamic return type

[Simn]

The problem is that the underlying type of Int64 is recursively resolved as Dynamic via Int64_t. The argument type of mul_i64 is Int64_t and thus not compatible because overloads check for type equality in that case.

The only question is which part of this is the bug.

[waneck]

Not sure I understand. Why is it that the argument type of mul_i64 is typed as Int64_t? Do you mean the this argument? I've ran into some other strange (seemingly related) typing issues when using the cpp cpp.Int64 type, but I haven't been able to reduce it yet

[delahee]

I am little worried by what you say...would be glad if you can dig this :)
Le 31 juil. 2014 00:11, "Cauê Waneck" notifications@github.com a écrit :

Not sure I understand. Why is it that the argument type of mul_i64 is
typed as Int64_t? Do you mean the this argument? I've ran into some other
strange (seemingly related) typing issues when using the cpp cpp.Int64
type, but I haven't been able to reduce it yet

—
Reply to this email directly or view it on GitHub
#3214 (comment)
.

[waneck]

The cpp issue seems to be related with a typing error on the @:op function which gets incorrectly caught - so the compilation continues without it. Still need to go back a few versions to see if I can reproduce it.

[Simn]

Yes it's about the this argument because your @:op method is not static. I kind of regret allowing non-static methods for this, but we'll have to deal with it now.

[Simn]

I can fix this for your concrete case, but the fact that the underlying type could be a typedef is giving me a headache. We cannot follow this early...

[nadako]

can we deprecate non-static ops?

[fponticelli]

Can you elaborate on the differences between implementing @:op as a static
vs instance method?
I thought they were equivalent.

Thanks.

On Wed, Jul 30, 2014 at 10:42 PM, Simon Krajewski notifications@github.com
wrote:

Yes it's about the this argument because your @:op method is not static.
I kind of regret allowing non-static methods for this, but we'll have to
deal with it now.

—
Reply to this email directly or view it on GitHub
#3214 (comment)
.

[Simn]

It's an implementation detail which causes trouble here. The compiler adds a "this" argument to abstract instance methods at syntax level, the type of which being that of the underlying type (again, at syntax level).

If you have abstracts over abstracts this means that "this" will be typed as the underlying abstract, not a real concrete type. This then makes the type equality check fail.

On the other hand the problem would still exists in the static version I suppose, so this might be a bit of a design issue.

[Simn]

@waneck: Can you run some tests with the latest commit?