Should static extensions really be applied through implicit casts?

[back2dos]

Having seen #5888 reminded me of how this current behavior creeps me out: if there's a static extension for type A and there's an implicit conversion from another type B to A, then all static extensions for A are applied to B also.

Here's an example:

using Test;

class Test {
    static function main() {
        0.bar();//<-- can call static extensions of `Foo` because there's a `@:from Int`
        0.baz();//<-- but cannot call methods of `Foo`
    }
    
    static function bar(f:Foo)
    	f.bar();
}

abstract Foo(String) {
    
    inline function new(v) this = v;
    
    @:from static function ofInt(i:Int) 
      return new Foo('$i');
    
    public function bar() {};
    public function baz() {};
}

This strikes me as pretty weird overall and quite inconsistent also. I really think static extensions should behave like methods as far as possible, but certainly not be applied more liberally. If anything, it is @:forward over abstract Abstract(Underlying) that should allow applying static extensions to Underlying to Abstract. The current behavior can be pretty unintuitive and introducing new implicit casts has far reaching and often undesireable effects:

using Test.FooTools;
using Test.BarTools;

class Test {
    static function main() {
        var foo = new Foo('foo');
        trace(foo.toString());//yields "Foo: foo" but uncomment the implicit Bar from Foo conversion below and you get "Bar: foo" because the static extension for Bar will get precedence over the static extension for Foo even though the type being dispatched on is Foo
    }    
}

abstract Foo(String) {
  public inline function new(s) this = s;
}

abstract Bar(String) {
    public inline function new(s) this = s;
    //@:from static function ofFoo(f:Foo) return new Bar('$f');
}

class FooTools {
    static public function toString(f:Foo) return 'Foo: $f';
}

class BarTools {
    static public function toString(f:Bar) return 'Bar: $f';
}

I keep on running into this repeatedly and it forces me to think very carefully about the order of my static extensions to avoid passing through unnecessary (and potentially expensive) implicit conversions. Not only that, I have to recheck the order every time I add a new implicit conversion. It is a breaking change of behavior became specified in #2152, but I really think the issue then was that the compiler silently generating invalid code and rejecting the code all together would have been the right call. Since there is no mention of static extensions being applied through implicit casts in the manual, my preference would be not to have to wait for Haxe 4.

[Simn]

Related: #5790

I think I agree, but I'll have to check the consequences of changing this.

[Simn]

Does anyone have any opinions on this? It's one of the things I consider breaking for Haxe 4.

[back2dos]

Adding to my "deliberations" above, I would also like to mention that this would also remove some of the problems with operator overloading through static extensions (as far as I understand).

[gene-pavlovsky]

Juraj's logic makes total sense to me.

[gene-pavlovsky]

I have no idea why @Simn was unassigned when I just left a comment

[Simn]

#2152 has a conflicting test, but that's the only failure in our tests.

Let's break it

[Simn]

I'm holding back on this until I have a solution for #7142.

[kevinresol]

Is this change intentionally apply only to @:from fields but not from directives?

FYR the following code still generates BarTools.stringify({ i : 1}):

using Main.FooTools;
using Main.BarTools;

class Main {
	static function main() {
		var foo:Foo = {i:1}
		trace(foo.stringify());
	}
}

typedef Base = {i:Int};
@:forward abstract Foo(Base) from Base {}
@:forward abstract Bar(Base) from Base {}

class FooTools {
	public static function stringify(v:Foo) return 'Foo ' + v.i;
}

class BarTools {
	public static function stringify(v:Bar) return 'Bar ' + v.i;
}