DartVM: factory constructors issues

[DartBot]

This issue was originally filed by ief...@unipro.ru

---

The spec v0.06 states:

It is a compile-time error if M is not the name of the immediately enclosing class or the name of an interface in the enclosing lexical scope.

consider the following test:
typedef foo();

class C {
  C() {}
  factory foo() {}
}

main() {
  new C();
}

This test should fail with compile-time error, however it compiles fine.

One more test:

class S {}

class C extends S {
  C() {}
  factory S() {}
}

main() {
  new C();
}

class S provides the implied interface which should be fine to use as a factory constructor name in C. However, the following compile-time error is produced:

Error: line 18 pos 12: static function 'S.' of class 'C' conflicts withinstance member 'S.' of super class 'S'.

  factory S() {}

What version of the product are you using? On what operating system?
DartVM r2810

Please provide any additional information below.
co19 tests:
LangSpecTest/07_Classes/5_Constructors/2/Factories/A05/t03
LangSpecTest/07_Classes/5_Constructors/2/Factories/A05/t02

[dgrove]

Added Area-VM, Triaged labels.

[iposva-google]

Marked this as being blocked by #1031.

[iposva-google]

Matthias, can you please work with Gilad to resolve whether these are still expected to be compile-time errors and whether they should be. See the blocking bug.

---

cc @gbracha.
Set owner to @mhausner.
Added Accepted label.

[gbracha]

The first example relates to a rule that is very likely to be relaxed into a static warning. So while it should indeed give a compiler error today, it will almost certainly not do so in the near future. So I would not invest time fixing it.

It does however bring up an interesting question: is a typedef an interface? The test writer assumes it is not. That assumption is only true for function types, though we might specify how to interpret a function typedef as an interface as well.

The second example is brilliantly perverse. It should be legal per spec, even though it is quite useless. Perhaps it should be made into an error or warning however.

[DartBot]

This comment was originally written by @seaneagan

---

I don't think a function typedef can be specified as a nominal interface, since it defines a structural/duck type (along with an alias for it). More generic structural typedefs might be nice though:

typedef Addable<E> {
  E operator +(E other);
}

Then for example you could define a SummableCollection which requires its type argument to be Addable, but doesn't require the author of the type used as the type argument to know or care about Addable:

interface SummableCollection<E extends Addable<E>> extends Collection<E> {
  E sum([E zero/* = null*/]);
}

Also, this would allow a function typedef such as:

typedef R Nullary<R, T>(T x);

to desugar to the following structural "interface":

typedef Nullary<R, T> extends Function {
  R operator call(T x);
}

[gbracha]

Obviously, the function type itself is not an interface, as the spec makes clear. One could choose to interpret it in a suitable way however - as an interface with an appropriately typed call method.

[DartBot]

This comment was originally written by @seaneagan

---

I think it would be incorrect to say that a (structural) function typedef is the same as a (nominal) interface with an appropriately defined call operator. However, structural types could be thought of as union types of all possible nominal types with the same structure, so function typedefs could be considered union types of all interfaces which define appropriately typed call operators (and extend Function?).

[DartBot]

This comment was originally written by rodion...@unipro.ru

---

even though the bug is a bit dusty, this probably still belongs here:
Language/07_Classes/6_Constructors/2_Factories_A05_t01
Language/07_Classes/6_Constructors/2_Factories_A05_t03
Language/07_Classes/6_Constructors/2_Factories_A05_t04
produce no compile-time errors when a class declares a factory constructor with a different name, though spec says they should:

It is a compile-time error if M is not the name of the immediately enclosing class (7.6.2)

[iposva-google]

Is this report still valid?

---

Set owner to @gbracha.

[gbracha]

Both the examples in the original report are still compile time errors. The spec now says

It is a compile-time error if M is not the name of the immediately enclosing class. (7.6.2)

[iposva-google]

Removed Priority-Medium label.
Added Priority-Unassigned label.

[lrhn]

The problem appears to be solved. Both the original examples fail with a message saying the constructor name must be C.

---

Added Fixed label.