[js] Type mismatch when using Bool default values

[jgranick]

Using recent sources of the Haxe compiler, there appear to be mismatches when using Bool default values.

For example, there is an interface that defines a function with an optional Bool parameter. There is a class that implements the interface, which also has the optional Bool parameter.

Something like this:

interface ITest extends IAnotherInterface {

   function hello (world:String, cool:Bool = true):ISomeOtherInterface;

}

class TestImpl implements ITest {

    ...

    public function hello (world:String, cool:Bool = true):ISomeOtherInterface {

        ...

    }

}

When compiled, the compiler says that the class' default Bool value is really Null<Bool>, while the interface remains Bool. The types are not the same, and it throws a compile error.

If this were the real code, it would throw an error that String->Null<Bool>->ISomeOtherInterface should be String->Bool->ISomeOtherInterface and that it overrides the parent class (yes it uses the words "parent class") with the wrong type.

Interestingly (and lucky for me!) this does not occur if all parameters have a question mark. ?myValue:Bool = true is consistently Bool in all cases. It's using only myValue:Bool = true (which the code all originally uses) that results in the Null<Bool> issues.

Magically, this works:

interface ITest extends IAnotherInterface {

   function hello (world:String, ?cool:Bool = true):ISomeOtherInterface;

}

class TestImpl implements ITest {

    ...

    public function hello (world:String, ?cool:Bool = true):ISomeOtherInterface {

        ...

    }

}

I don't know if this would consistently happen all the time, or it's some combination of interfaces extending interfaces being implemented on classes extended by other classes. I don't know, but I wonder if the question mark exception here is intentional, or is how this issue was undetected (as I think all the Haxe test code uses question marks for optional values?)

The question marks should be optional, I am thankful for a workaround, but maybe you guys have an idea of the root cause? I believe it only affects 3.3 dev builds

[Simn]

I cannot reproduce the problem with this:

interface ISomeOtherInterface { }
interface IAnotherInterface { }

interface ITest extends IAnotherInterface {
   function hello (world:String, cool:Bool = true):ISomeOtherInterface;
}

class TestImpl implements ITest {
    public function hello (world:String, cool:Bool = true):ISomeOtherInterface {
        return null;
    }
}

Any more hints? Does it only happen on a specific target?

[Gama11]

Does it only happen on a specific target?

The issue title says "js".

[Simn]

Oh right! But I can't reproduce it on JS either.

[jgranick]

It's part of a very complex codebase. It's something like:

interface IModel {
    public function foo (a:Int, b:String):Dynamic;
    public function foo2 (a:Bool, b:Int):Void;
}

interface IListModel extends IModel {
    public function foo3 (a:Float, b:Bool = true):IOtherModel;
}

class ListModelImpl implements IListModel {
   ...
}

class OtherListModelImpl extends ListModelImpl implements YetAnotherModel {
   ...
}

I have a sinking feeling it may be hard to reproduce outside the original codebase, which I can't share (unfortunately). I had a feeling that the JS-specific nature and "question mark fixes the issue" characteristics might lend some clues to where or what in the code leads to this.

On a dynamic target, I assume Null would most of the time fly invisibly under the radar, but since it needs to subscribe to an interface, that's where trouble comes. Even more curiously, on the "ListModelImpl" class, it even says that "notifyListModel" overrides the parent class with a bad type. It has no parent type, other than an interface, and the interface has no such function (though it has a few that start with "notify"), so it's all very curious.

Layer upon layer upon layer

[Simn]

Well, ? does imply nullability so in that case you end up with a Null<Bool> type. But yes, I have no idea why a Null<T> T unification would ever fail, dynamic target or not.

Maybe a bisect is necessary.

[Simn]

Actually that's not true, Null<T> T is checked for redefinitions here: https://github.com/HaxeFoundation/haxe/blob/development/typeload.ml#L706

I have made a change to this line recently: 4557c34

However, that should only affect things if Dynamic is involved. Can you try if reverting this change removes the error on your end?

[jgranick]

The version of Haxe used was compiled from this source version:

f7fa452

This appears to be two days before the Dynamic change you made.

I hoped this commit would make a difference:

d86d452

...but I updated to the latest source from yesterday, same problem 😢

I believe the issue is still type mismatches (such as with an interface), not issues with passing parameters, though it is strange that errors occurred for at least one field that was not part of an interface or a parent class.

Although the error occurs when using interfaces, its interesting that error occurs on the "override" code path, not the interface code path:

https://github.com/HaxeFoundation/haxe/blob/development/typeload.ml#L889-L891

[jgranick]

I just got the same error again, let me share the error output:

path/to/Container.hx:120: lines 120-140 : Field setPrincipalComponentAndWalk overloads parent class with different or incomplete type
path/to/ActionOverlayView.hx:29: lines 29-117 : Defined in this class
path/to/Container.hx:120: lines 120-140 : child : com.framework.IFocusableComponent -> ?stopAtLayer : Null<Bool> -> Void should be child : com.framework.IFocusableComponent -> ?stopAtLayer : Bool -> Void
path/to/Container.hx:120: lines 120-140 : Null<Bool> should be Bool
path/to/ActionOverlayView.hx:29: lines 29-117 : Defined in this class

The relevant function looks like this:

private function setPrincipalComponentAndWalk(child : IFocusableComponent, stopAtLayer : Bool = false) : Void { ... }

This occurs a few times, for basically any value:Bool = true parameter in the functions on these classes. I think it is related (somehow?) to these classes implementing interfaces, though not extending any base class. It is curious.

[Simn]

Are you sure you don't have value:Bool = null anywhere? This would infer the type as Null<Bool> and cause the observed error.

[jgranick]

I just hit an area of code that got upset about openfl.events.IEventDispatcher, same problem. To fix the problem (temporarily), I added question marks to the IEventDispatcher interface. This now causes openfl.events.EventDispatcher to fail to compile. Perhaps, this at its core, is the root issue.

This original code works outside the project:

interface IEventDispatcher {

    public function addEventListener (type:String, listener:Dynamic->Void, useCapture:Bool = false, priority:Int = 0, useWeakReference:Bool = false):Void;
    public function removeEventListener (type:String, listener:Dynamic->Void, useCapture:Bool = false):Void;
    ...

}

class EventDispatcher implements IEventDispatcher {

    public function addEventListener (type:String, listener:Dynamic->Void, useCapture:Bool = false, priority:Int = 0, useWeakReference:Bool = false):Void { ... }
    public function removeEventListener (type:String, listener:Dynamic->Void, useCapture:Bool = false):Void { ... }
    ...

}

This modified code fails to compile... when I changed the interface to try and fix the other project, it broke EventDispatcher. The following does not unify:

interface IEventDispatcher {

    public function addEventListener (type:String, listener:Dynamic->Void, ?useCapture:Bool = false, ?priority:Int = 0, ?useWeakReference:Bool = false):Void;
    public function removeEventListener (type:String, listener:Dynamic->Void, ?useCapture:Bool = false):Void;
    ...

}

class EventDispatcher implements IEventDispatcher {

    public function addEventListener (type:String, listener:Dynamic->Void, useCapture:Bool = false, priority:Int = 0, useWeakReference:Bool = false):Void { ... }
    public function removeEventListener (type:String, listener:Dynamic->Void, useCapture:Bool = false):Void { ... }
    ...

}

I always think of the question mark as being superfluous syntax when assigning a default value. It actually, in the current compiler and the JS target, results in Bool versus Null<Bool> which results in compile errors.

Do you think that we should treat all value:Bool = true parameters as a Null<Bool>, similar to using a question mark, or do you think that (on the reverse) ?value:Bool should be treated as value:Bool = false and not type as Null<Bool>?

If both are treated consistently, it may solve our problem. C++ (among other targets) definitely work with the code, so it seems related either to being a dynamic target, or maybe the JS code compilation process specifically.

Thank you!

[Simn]

As I said ? implies nullability. I have argued before that ?name:Bool should be a compiler error because it becomes ?name:Null<Bool> which effectively ignores the explicit type-hint. The same is true for name:Bool = null.

Let's try to get an overview:

argument	nullable	optional
?name	true	true
name = null	true	true
name = value	false	true
name:Null<T>	true	false
name:Null<T> = value	true	true

[jgranick]

Hmm, I don't think there is an = null in the code, that I could tell. Something about the layers of complexity is typing it to Null<Bool> at some point, which causes a reaction of mismatching types.

It is still curious to me that other platforms (notably C++) are not having compile errors, I wonder if the type is inferred to Null<Bool> at some point due to convenience, or expecting that omitting the default value on JavaScript would end up being null at some point.

The way it reacts about functions on a class with no parent type, unrelated to interfaces used, responding that it overrides with the wrong type, almost suggests to me that one pass (macro pass?) is typing something as Null<Bool>, then the next pass properly types as Bool and gets upset, or vice versa, on the same method.

I assumed that ? on Bool values implied false, and on Int or Float implied 0 as the default value, but it makes sense to have it consistent. It isn't originally used in this code, I've been applying it as a workaround to this strange problem

[jgranick]

The real issue of grief comes from Null<Bool> should be Bool errors. When looking at the code, it clearly states name:Bool = true.

"It already is Bool, not Null, what am I supposed to do?!" (╯°□°）╯︵ ┻━┻)

If you would like to tighten things up so the error occurs elsewhere (not allowing value:Bool = null ... though I'm not sure that's the true cause in the code I'm testing) I don't mind, or if Null<T> and T can unify on dynamic targets, perhaps it should not throw the type errors during compilation and be more lenient.

If ? remains nullable by default, I would suggest that it does not for explicit types, like this:

argument	nullable	optional
?name	true	true
name = null	true	true
name = value	false	true
?name = value	true	true
?name:T = value	false	true
name:Null<T>	true	false
?name:Null<T>	true	true
name:Null<T> = value	true	true
?name:Null<T> = value	true	true

I've always thought of ? as being similar to public and private in classes and enums, they are implied by default, but you can specific about it if you prefer to be verbose or clear. The key difference would be that ?name:T = value would not be nullable, as you suggested you argued for.

HOWEVER -- that won't fix the problem I'm having, it would remove my workaround to get the code to compile on the JavaScript target, and instead of adding ? I would have to also change all the Bool types to Null<Bool> explicitly, which would be good if that's what I wanted, but I'd prefer these to just be regular Bool as they were in the original project 😄

[Simn]

I have improved error reporting, it now reports the position of the base/interface field as well like so:

Main.hx:5: lines 5-8 : Field v has different type than in I
Main.hx:2: characters 8-28 : Interface field is defined here
Main.hx:5: lines 5-8 : String -> Void should be Dynamic -> Void
Main.hx:5: lines 5-8 : String should be Dynamic

This tells you exactly which two field the compiler "compares". Please paste the signatures of both fields so we can be sure they are indeed equal.