abstract @:to casts are not considered for operators

[nadako]

abstract A(Int) from Int {
	@:to function toInt():Int return this;
}

class Main {
	static function main() {
		10 + (10 : A);
	}
}

This gives A should be Int, however I would expect it to call toInt(), especially considering that adding direct to Int works.

[nadako]

This is not a regression, but still would be very nice to fix for 4.0

[Simn]

This is a bit controversial because the lhs has nothing to do with the rhs in this case. I don't have a good strategy for this at the moment so it's unlikely that we'll do anything for 4.0 here.

[nadako]

lhs has nothing to do with the rhs in this case

I'm confused, why to Int works then? Or it also should not?

[Simn]

I find that weird as well, but as I said I don't have a good strategy.

The reason it works is probably due to the compiler defaulting to unify_int and that just trying a normal unification, which then happens to work.

[nadako]

BTW this is a reduced case of something more complicated I had in my code:

abstract A(Int) from Int {
	@:to function toInt():Int return this;
	@:op(a+b) static function f(a:A, b:A):A return 10;
}

class Main {
	static function main() {
		var x = 10;
		x = x + (10 : A); // works, toInt called
		x += (10 : A); // doesn't work 🤷‍♂ 
	}
}

[RealyUniqueName]

x = x + (10 : A); // works, toInt called

Actually, this works because x is casted to A because of from Int and @:op(a+b) static function f(a:A, b:A).
You can add @:op(a+=b) static function f(a:A, b:A) and the failing line will work too.

What's our spec here, @ncannasse ? We have these options:

• from Int + @:op function(a:A, b:A) takes precedence
• to Int takes precedence

(from and to here also means @:from and @:to as I beleive both implicit casts should behave the same way here)

[nadako]

Actually, this works because x is casted to A because of from Int and @:op(a+b) static function f(a:A, b:A).

Well, it's actually because the return value of f is also A which has @:to Int.

You can add @:op(a+=b) static function f(a:A, b:A) and the failing line will work too.

That does not generally work at all, because a is tempvared, so the original left-hand expression is left unchanged.

[RealyUniqueName]

Actually, we have another option:

• don't allow implicit casts in operators overloading

[back2dos]

I can absolutely see why one would want that to work, but I prefer erring on the side of caution here and follow Alex's advice to disallow implicit casts in operator overloading. It's already pretty banged up:

abstract A(Int) {
  @:to function toInt():Int {
    trace('A to Int');
    return this;
  }
  @:from static function ofInt(i:Int):A
    return cast i;
}
abstract B(Int) to Int {
  @:from static function ofInt(i:Int):B
    return cast i;
}
abstract C(Int) from Int {
  @:to function toInt():Int return this;
  @:op(a+b) static function f(a:C, b:C):C 
    return 10;
}
class Test {
  static function main() {
    var x:C = 10;
    x = x + (10 : A); 
    x = x + (10 : B);// cannot add C and B
  }
}

If anything, it should work the other way around, as to is "stronger" than @:to. My preference would be to disallow it entirely until we can produce a solid and predictable selection algorithm that is not entirely unintuitive. You need to deal with cases like where you have an A and B with A+A and B+B respectively and there are multiple casts between A and B it needs to be clear which + "wins".