Haxe function typing incompatibilities with static targets - HaxeFoundation/haxe GitHub Wiki

Currently, the way Haxe functions are typed make it work very sub-optimally on some situations in static targets. Here we list some of these cases:

var fn:Float->Int->Int = someFunction;
var fn2:Int->Int->Float = fn; // legal :(
var fn3:Dynamic->Dynamic->Dynamic = fn; // legal :(
var fn4:Null<Int>->Null<Int>->Int = fn; // ugh...
var fn5:Null<Int>->Dynamic->Dynamic = fn; // guess what? Legal...

function doSomething<T>(i:Float, i2:Null<T>):T {
  return i2;
}

fn = doSomething; // it's always tricky to deal with pointers to generic functions. But this is specially hard

This problem was the base on some decisions on for example the C# target, where every argument is sent in both an object (dynamic) form, and a double form (to avoid unboxing when possible). Using C# delegates on this environment wasn't possible, due to the constraints (specially involving reflection/dynamic).

Generics always make handling typed functions more challenging. In special, generic function pointers, or generic functions that return other generic functions. For example, a simple function like

function doSomething<T>(v:T):Void->T { return function() return v; }

Is hard to deal with that signature, since for example in C# - as soon as you use a type parameter, any difference in handling type parameters between Haxe and C# will make the final function have the incorrect signature