Rudy Ges

Probably because of https://github.com/HaxeFoundation/haxelib/blob/development/src/haxelib/api/ScriptRunner.hx#L94, which is also triggering some issues for me (because I don't have a global repository, it breaks easily)

It is not the same. Now not only cwd but also resolution of path to haxelib repo is impacted, as it's resolved from that cwd instead of "real" cwd.

I don't think I'll have time today, so will look at this tomorrow. It likely breaks some workflow I use from time to time (using git dependency, and doing git...

Try pinning extlib to 1.7.9

I checked 4.3.6 build logs vs what Eric is getting, and he's getting 1.8.0 (which is incompatible with 4.3_bugfix?) while 4.3.6 was built with 1.7.9

That would likely break a lot of things.. 🤔 However I do think this shouldn't be allowed with null safety enabled

A similar example where at least this should not trigger double `Null` wrapping: ```haxe function main() { var x:Null = ""; var zz = testfn(x); $type(zz); // Null } function...

This is still wrong.. monomorph is closed, which breaks the following: ```haxe static function doThingsImpl(foo) { $type(foo); // Unknown foo.doWithBar(); $type(foo); // Unknown : { doWithBar : () -> Unknown...

> My intuition here would be to only do this `Null` binding if the expected type is an _unconstrained_ monomorph. Sounds like it would only cover a few use cases...

Yeah, that sounds like a necessary rabbit hole (but I guess other constraints could be added later if needed rather than all at once). I started a POC adding that...