Args without type hints in overriden functions are monomorphs

[RblSb]

typedef Size = {width:Float}

class Parent {
	public function onResize(size:Size):Void {}
}

class Main extends Parent {
	static function main() {}
	// Field onResize overrides parent class with different or incomplete type
	// error: { width : Int } should be Size
	override function onResize(size) { // works with Size type hint
		if (size.width == 0) {}
	}
}

[back2dos]

The thing is that this is valid:

class Parent {
  public function new() {}
  public function onResize(size:{ width: Float }) {}
}

class Child extends Parent {
  override public function onResize(size:{}) {}
}

Function arguments are contravariant in subtyping. This is perfectly valid:

final size = { width: 123 }; 
new Child().onResize(size);

Unfortunately, monomorphs have only upper constraints (i.e. "must be subtype of") and no lower constraints ("must be super type of"), so there's no practical way of even constraining the monomorph. If there were, then in your example the compiler could correctly infer that size.width is a super type of Float (not that there are many) and then size.width == 0 would actually be float comparison.

For a less sophisticated solution one could in principle support something like this (might require parser adjustments):

class Parent {
  function onResize(size:{ width: Float }) {}
}

class Child extends Parent {
  override function onResize(size: super) {}
}

Or in general there could be some syntax to say "copy the full signature from super type", with some meaningful error if that leads to ambiguity.

[RblSb]

Yeah, when there is no typehints, i feel like that infering super types of args/return is much better behavior than generating monomorphs. If i want to override something with narrower type, i would like to specify that explicitly, or i can get same wrong type inference too easily.

[back2dos]

I'm inclined to agree that it would be more convenient and that it seems to make for a better default (I vaguely remember asking for this mysefl years ago). But perhaps this should be properly explored in a proposal, because there's a whole bunch of subjects to cover:

• for argument types it seems relatively trivial, but the question then becomes what if there's an overlap between super types
• for return types it becomes trickier, because you have two options:
  1. assume the super type - but this can be awkward, when there's a return statement that clearly produces a narrower type, that even makes sense
  2. infer normally - gives you a lot of stuff for free, but you do lose top down inference

It's this type of murkiness that often gets convenience improvements rejected: you trade one set of edge cases against another. You'd have to harden the case for your preference ;)

The specific situation for which I'd want something like this is when you have a lot of generics and functional types involved, where respecifying the signature on the sub type becomes superbly annoying. In the base type, all the parameters were single letter or short names, and then the concrete types are longer, you suddenly wind up with a wall of types that adds zero information to what's already established per the sub typing and it often becomes a nightmare to deal with the fallout from trivial changes to the base type. Hence I proposed the : super or some way of explicitly telling the compiler: "the super type is the source of truth here".

So I guess what I'm saying:

• I can see that the powers that be might not consider getting types from the super type as a sensible default
• if this doesn't become the default behavior, there is still a point to be made for allowing the user to opt into it when needed