Check The Robert Issue

[Simn]

So I don't forget: There's a potential problem with access on something that tries really hard to not look like Dynamic picking up non-Dynamic static extensions.

[nadako]

using Main.Ext;

abstract D(Dynamic) to Dynamic {}

class Ext {
	public static function round(f:Float) {}
}

class Main {
	static function main() {
		var d:D = null;
		d.round();
	}
}

[nadako]

(replacing to Dynamic with a @:to Dynamic method will prevent this BTW)

[Simn]

That makes it a variant of #5924 and the question Kevin asked in the last comment there becomes relevant.

Now I'm somewhat worried about breaking this (for to Dynamic in particular), but it's hard to tell if anyone intentionally relied on this behavior.

[vonagam]

This change forbid not only dynamic to anything, but other types of implicit casts one might consider non-dangerous.

Examples (connected to #9652):

using Lambda;
using Main.ParentTools;

abstract Foo<T>(T) from T to T {}

class Parent { public function new() {} }

class Child extends Parent {}

class ParentTools { public static function tool(that: Parent) {} }

class Main {
  public static function main() {
    var parentFoo: Foo<Parent> = new Parent();
    parentFoo.tool();

    var childFoo: Foo<Child> = new Child();
    childFoo.tool(); // error

    var arrayFoo: Foo<Array<Int>> = new Array<Int>();
    arrayFoo.count(); // error
  }
}

So now to Array<Int> isn't enough for Lambda extensions to be picked up, and to Child is not enough for ParentTools (and in the example Foo can't work around this, as he doesn't know anything about T).

Question: is this intended result of the change or just an unplanned consequence?

[RealyUniqueName]

@Simn ?