Skip to content

relax function subtyping #2706

Closed
Closed
@sigmundch

Description

@sigmundch

I'd like to consider relaxing the function subtyping rules from Section 13.5 of the spec.

I recently run into limitations with the current rule that I think are unnecessary. Consider this example:

typedef Dynamic Fun1(Dynamic p);
typedef Dynamic Fun2([Dynamic p]);

f1(p) => print("1 $p");
f2([p=null]) => print("2 $p");

main() {
  Fun1 test1 = f1;
  Fun2 test2 = f2;

  Fun1 test3 = f2; // error today, would be OK if we change the rules
  Fun2 test4 = f1; // error today, should continue to be error

  test1("hi1");
  test2("hi2");
  test3("hi3"); // this could be allowed if we change the rules.
  test4("hi4");

  test4(); // this error is correctly prevented by the current rules

}

In this example, the type system will give errors on the assignment of test3 and test4. I claim that test3 should be considered a valid assignment, but test4 continue to be an error.

In terms of the type system. Currently we compare these 2 types:
(T1, ... Tn, [Tx1 x1, ..., Txk xk]) -> T
(S1, ... Sn; [Sy1 y1; ..., Sym ym]) -> S

And we force that the total number of positional arguments (n) is the same.

I'd like to relax by considering the named arguments of the second type a possible replacement for missing positional arguments, that is:
(T1, ... Tn, [Tx1 x1, ..., Txk xk]) -> T
(S1, ... Sj; [Sy1 y1; ..., Sym ym]) -> S

The rules could check that j + ym >= n. Let yn be such that j+yn = n. Then compare (T1... Tn) with (S1 ... Sj Sy1 ... Syn).

Metadata

Metadata

Assignees

Labels

area-languageDart language related items (some items might be better tracked at github.com/dart-lang/language).type-enhancementA request for a change that isn't a bug

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions