should expected type be propagated through type params

[nadako]

Sorry, this question was probably asked and discussed before, but I'm in the middle of work atm and can't find the issue.

So consider the following code:

extern class Vector<T> {
	static function ofArray<T>(v:Array<T>):Vector<T>;
}

class Base {}

class Child extends Base {
	public function new() {}
}

class Main {
	static function main() {
		var v:Vector<Base> = Vector.ofArray([new Child()]);
	}
}

this currently gives:

Main.hx:13: characters 3-54 : error: Child should be Base
Main.hx:13: characters 3-54 :  have: Vector<Child>
Main.hx:13: characters 3-54 :  want: Vector<Base>

which is understandable, as ofArray call receives [new Child()] with an expected type of just Array<T>, so it binds T to Child and returns Vector<Child>.

My question is: is it possible (and safe) to actually propagate the expected type through type parameters so the example above compiles?

[ncannasse]

The problem is more the following:

in case there's an actual mismatch between the expected type and the one we pass into the Array, what would the error look like in that case ? I think that would be a bit too hard to understand for the user which would get "Child should be Base" on the "new Child" expression.

So I would prefer that we don't consider this

[nadako]

Yeah, that's a concern, but if we somehow could add the "expected type propagated through type parameters" or something to the error message, I think that would be sufficient.

[back2dos]

I created a duplicate at #10036, unaware of this one. I have added some thoughts there I would like to get comments on.

[Simn]

I'm having a hard time understanding what the correct behavior is. In particular, it's not clear to me what should happen in what order, and what kind of failures we can recover from.

For instance, anything involving abstract @:to and @:from casts could lead to situations where an early unification of the return type fails, even though assigning the expression to the expected type would work. This means that we would still require the current behavior as a fallback, and then we have the usual problem with double-typing and potential side-effects again.