Inconsistent interface type inference for getters/setters

[RblSb]

interface IObj {
    var width(default, null):Float;
    var height(get, set):Float;
}

class Main implements IObj {
    public var width(default, null) = 0; // Int in this implementation

    @:isVar public var height(get, set) = 0.0; // cannot be Int here, but

    function get_height():Int { // no signature error
        return Std.int(height);
    }

    function set_height(height:Float):Int { // fine too
        return Std.int(height);
    }

    public function new() {}

    static function main() {
        final m = new Main();
        int(m.width); // fine int
        int(m.height); // Error: Float should be Int
    }

    static function int(v:Int):Void {
        trace(v);
    }
}

[pecheny]

What's wrong with that? Getter and setter are implementation details compatible with the contract as long as Void->Int is a subtype of Void->Float, covariance stuff and all...

class Test {
  static function main() {
       var myFunc:Void->Float = foo;
  }

  static function foo():Int {
    return 0;
  }
}

Main is also a subtype of IObj with its own width:Int, as long as read-only access is covariant on the return type.

[RblSb]

Yes, i think implementing Float as Int should be allowed, this is pretty handy for subclasses to restrict Float a little. But it doesn't work in all cases, only for (default, ...), but not for get, set or simple fields:

interface IMain {
    var a(default, never):Float;
    var b(default, null):Float;
    var c:Float;
    var d(get, set):Float;
}

class Main implements IMain {
    public var a:Int = 0; // fine, good
    public var b:Int = 0; // fine, good
    public var c:Int = 0; // Field c has different type than in IMain
    public var d(get, set):Int; // Field d has different type than in IMain

    function get_d():Int
        return 0;

    function set_d(d:Float):Int
        return 0;

    static function main() {
        final main = new Main();
        // Allowed because there is no `a(default, never)` in Main, bad
        main.a = 1;
    }

    public function new() {}
}

And there is another bug, you can have more restricted type in interface with (default, never), but compiler will not inference (default, never) to your implementation.

[pecheny]

It should work for read access only. In case of write access relation is also a contravariant so subtyping is impossible. public var d(get, set):Int should accept Float for writing by contract so compilation error is correct for this case. The same for second case: interface may and should be more restricted than implementation but not vice versa.