Tests for `void`.

tests/language/void_type4_test.dart

Index: tests/language/void_type4_test.dart
diff --git a/tests/language/void_type4_test.dart b/tests/language/void_type4_test.dart
new file mode 100644
index 0000000000000000000000000000000000000000..8d1c2ea525788d2467edfd4341b8dbccced4d95a
--- /dev/null
+++ b/tests/language/void_type4_test.dart
@@ -0,0 +1,120 @@
+// Copyright (c) 2017, the Dart project authors.  Please see the AUTHORS file
+// for details. All rights reserved. Use of this source code is governed by a
+// BSD-style license that can be found in the LICENSE file.
+
+// Dart test for type checks involving the void type.
+
+import 'package:expect/expect.dart';
+
+use<T>(T x) {}
+
+class A<T> {
+  T x;
+  Object y;
+  int z;
+
+  T foo() => null;
+  void bar() {}
+  void gee(T x) {}
+
+  f(A<Object> a) {}
+  g(A<void> a) {}
+  h(A<T> a) {}
+}
+
+class B implements A<Object> {
+  var
+  void   /// 00: error

[Lasse Reichstein Nielsen, 2017/02/21 09:37:04]

That looks wrong. "var void x;" isn't valid syntax. Should it be something like:

void /// 00: error
/*   /// 00: continued
var 
*/   /// 00: continued
x;

?

[floitsch, 2017/02/22 14:44:43]

Done.

+  x;
+
+  var
+  void   /// 00b: error
+  y;
+
+  int
+  void   /// 00c: error
+  z;
+
+  void  /// 01: error
+  foo() => null;

[Lasse Reichstein Nielsen, 2017/02/21 09:37:04]

Say what the problem here is.
It's overriding an Object function with a void function, right?

[floitsch, 2017/02/22 14:44:43]

Done.

+
+  int bar() => 499;
+  void gee(
+    void   /// 02: error

[Lasse Reichstein Nielsen, 2017/02/21 09:37:04]

I don't think this should be an error.

It's overriding a "void gee(Object x)" with either "void gee(dynamic/Object x)"
or "void get(void x)". Either should be valid overrides.

[floitsch, 2017/02/22 14:44:43]

right.
done.

+    x) {}
+
+  f(A<void> a) {}
+  g(A<void> a) {}
+  h(A<void> a) {}
+}
+
+class C implements A<void> {
+  void x;
+  Object y;
+  int z;
+
+  void foo() {}
+  void bar() {}
+  void gee(void x) {
+    use(x);  /// 03: error
+  }
+
+  f(C c) {}
+  g(C c) {}
+  h(C c) {}
+}
+
+class D implements A<void> {
+  Object x;  /// 04: ok?   should be ok, but the setter goes from void to Object.

[Lasse Reichstein Nielsen, 2017/02/21 09:37:04]

The getter is fine, but the setter isn't. This is a case of overriding a
(generically covariant) method in a covariant and non-generic way. 
I think you have argued that this shouldn't be allowed. The fact that void is
involved shouldn't change that.

[eernst, 2017/02/21 13:39:12]

We have the following overriding relationship:
  A<void>: void get x
  D:       Object get x
  A<void>: void set x(void value)
  D:       void set x(Object value)

The getter just follows the pattern we always had, so that's not allowed to be a
problem.

For the setter, if we use Dart 1 rules and consider `Object <: void` to hold,
this would be a covariantly overridden parameter type, which is OK. So it should
be allowed in Dart 1.

+  Object y;
+  int z;
+
+  Object foo() => null;
+  void bar() {}
+  void gee(
+    Object  /// 05: error

[Lasse Reichstein Nielsen, 2017/02/21 09:37:04]

This is effectively the same signature as the setter for x.

[eernst, 2017/02/21 13:39:13]

Same issue: If we use Dart 1 overriding rules then covariant parameter types are
fine (no `covariant` modifier needed).

+    x) {}
+
+  f(A<Object> a) {}
+  g(
+    A<Object>  /// 06: error
+    a) {}
+  h(
+    A<Object>  /// 07: error
+    a) {}
+}
+
+void instantiateClasses() {
+  var a = new A<void>();
+  var b = new B();
+  var c = new C();
+  var d = new D();
+
+  a.foo();
+  b.foo();
+  c.foo();
+  d.foo();
+  a.bar();
+  b.bar();
+  c.bar();
+  d.bar();
+  a.gee(499);
+  b.gee(499);
+  c.gee(499);
+  d.gee(499);
+}
+
+void testAssignments() {
+  A<void> a1 = new A<Object>();
+  A<Object> a2 = new
+      A
+      <void>   /// implicit_downcast: error
+      ();

[eernst, 2017/02/21 13:39:13]

Yes, I think we should let the special treatment of downcasts from `void` bleed
into the generic type: Any number of levels could be involved before we reach
`void`, but it still counts as a "downcast from void" if the target type puts
any other type in place of `void`.

We could say that "isVoid(A<T>) == isVoid(T) for all A", and then apply the same
restrictions on casts from all "isVoid" types rather than just on the type
`void` itself.

We'd need to say more precisely what it means to "downcast from void", because
we should cover cases like `Map<void, void>` --> `Map<void, dynamic>` and
`Map<dynamic, void>` --> `Map<void, dynamic>` (both of which will enable certain
derived expressions to switch from `void` to some other type).

+  A a3 = new A<void>();  /// raw_assignment: ok?

[eernst, 2017/02/21 13:39:13]

In Dart 1 the type annotation `A` is definitely `A<dynamic>`, so this is again a
"downcast from void" via isVoid. This assumes that we consider `dynamic` and
`Object` to occupy the same location in the type graph, but we've said things
like that many times.

+  A<dynamic> a4 = new A<void>();  /// dynamic_assignment: ok?

[Lasse Reichstein Nielsen, 2017/02/21 09:37:04]

So, basically, the question is whether dynamic is (treated as) a supertype of
void or not?

I'd say not - void is "not a value" and dynamic is "any value".

[eernst, 2017/02/21 13:39:13]

Agreed, I'd want to make this an error, but the reasoning is that we downcast
from an isVoid type to a non-isVoid type, which counts as "downcast from void",
which is an error when statically known.

[floitsch, 2017/02/22 14:44:43]

What about `dynamic a5 = new A<void>()` then?
Added it to the test.

[Lasse Reichstein Nielsen, 2017/06/02 11:14:23]

I want to say "allowed".

Here you are not casting void-ness to non-void-ness, you are casting away
everything that even refers to the void. Casting a List<void> to Object doesn't
allow you to access any "void" members of the list - you don't even know that it
is a list, so not only does the void no longer exist in the static type, the
things previously typed as void also no longer exists in the static type.

There is some structurally recursive property here. A cast is disallowed if:
it casts void to a non-void type.
It casts T<..., A, ...> to T<..., B, ...> and the cast A->B is disallowed. 
This includes supertypes, so List<void> -> Iterable<dynamic> is disallowed
because List<void> is-a Iterable<void> and you are casting that to
Iterable<non-void>.

+}
+
+main() {
+  instantiateClasses();
+  testAssignments();
+}