Is there a reason "has extra fields" needs to generate an error?

1

Is there a reason that this code needs to generate an error?

class Test {
    static function main() {
        trace("Haxe is great!");
        var point3d = {x: 0, y: 0, z: 0};
        var point2d: {x: Int, y: Int} = point3d; // { z : Int, y : Int, x : Int } should be { y : Int, x : Int }
    }
}

I know some other type systems view “point3d” as a valid object to fit anytime “point2d” is required. See for example Flow

I found this old manual page saying “However please note that if the p3d variable is not typed as Point3D, the compiler will complain saying that there is an extra field z : this is because this field is not required by Point and is then useless.”

Is there any way to tell the compiler to accept my object, other than doing a cast or untyped? (That is: I would still like type checking on the fields that are there, I just want it to ignore extra fields).

2

Does it work if the fields are optional?

3

There’s a discussion about this here: Inconsistent structual typing of inferred anon-types. · Issue #3192 · HaxeFoundation/haxe · GitHub

4

Thanks @nadako… it’s interesting that the exact same issue was marked as fixed. Cheers for digging it up, I vaguely remember that discussion happening at the time :slight_smile:

@singmajesty in this case I am using a library (tink_sql) where I don’t have control over the typedef, so making the other fields optional isn’t an option in this case. Interestingly the code example in the issue Dan posted shows a workaround by avoiding Haxe seeing the object as a “constant” or something…