void is inconsistent about whether non-void values can be assigned to it

[Hixie]

I may be confused, but my understanding and intuition is that void means nothing, and something of type void cannot take on any values. This understanding is supported by the way that Dart doesn't let you return anything from void-returning methods:

void foo1() {
  return 0; // "The return type 'int' isn't a 'void', as defined by the method 'foo1'"
}

It also doesn't let you read anything from arguments that are explicitly typed void:

import 'dart:async';

void main() {
  final Completer<void> completer = new Completer<void>();
  completer.complete(0);
  completer.future.then((void value) {
    print(value); // "The expression here has a type of 'void', and therefore cannot be used"
  });
}

(In both these cases, these are only analyzer restructions; the compiler allows both. But that's fine, so long as one of them complains, I consider it "invalid Dart".)

Somehow, though, this doesn't always hold. For example, you can return a value from an async method that returns Future<void>:

Future<void> foo2() async {
  return 0; // no error (!!)
}

You can also pass values to methods expecting void with no ill effects:

void main() {
  final List<void> a = <void>[];
  a.add(0); // no error at analysis time or runtime (!!)
  print(a); // prints [0] (!!)
}

According to the analyzer, you can pass "void"-expecting objects into APIs that expect other types, though that is a runtime error in Dart2 (not Dart1):

void addNumber(List<int> list) {
  list.add(0);
}

void main() {
  final List<void> list = <void>[];
  addNumber(list); // no analyzer error, though the Dart2 runtime does throw here
  print(list);
}

You can pass non-void expecting objects into APIs that expect void objects, with unexpected results:

void printVoidList(List<void> list) {
  print(list); // prints [0] (!!)
}

void main() {
  printVoidList(const <int>[0]); // no error at analysis time or runtime (!!)
}

This leads to situations where you can be completely messing up the types, but neither the analyzer nor the compiler will complain. This code is based on actual code in the Flutter framework that tries to use generics to catch programmer errors, but currently fails to catch any errors because of this:

import 'dart:async';

List<Completer<dynamic>> pendingWork = <Completer<dynamic>>[];
     
int addWork<T>(Completer<T> work) {
  pendingWork.add(work);
  return pendingWork.length - 1;
}

void completeWork<T>(int index, T value) {
  pendingWork[index].complete(value);
}

void main() {
  Completer<int> completer = new Completer<int>();
  int index = addWork<void>(completer); // no error (!!)                                                                                                                                                                                                       
  completeWork<void>(index, 0); // no error (!!)       	                                                                                                                                                                                                       
  completer.future.then(print); // prints "0"                                                                                                                                                                                                                  
}

[Hixie]

In summary, I guess I don't understand why return 0 in a void-returning method is considered an error while completer.complete(0) on a Completer<void> is not. They seem to me to be semantically equivalent.

[MichaelRFairhurst]

Ah, I misunderstood the confusion (Null vs void rather than return vs arg).

So in this case you're right its pretty inconsistent and I agree with you.

I do think its important to clarify that allowing both or neither is not an issue of soundness -- void can not be used, so its "safe" to put anything (or nothing) inside a void value.

I say "safe" (with quotes) because it is usually not something people want to do -- statically determine that people want to put data somewhere that it can't be used! That said, drawing the line is kind of funky to determine.

final funcBug = (x) => ++x; // (int) -> int
final funcOk = (x) {  // (int) -> int
 print(++x);
 return x;
}

myInts.forEach(funcBug); // accepts (int) -> void, so this is safe, but useless, indicating a bug
myInts.forEach(funcOk); // accepts (int) -> void, so this is safe, and useful

In this example we can't statically determine when this is a Good idea or a bad one.

I think there are a few places where we can determine that its a bad one, such as void x() => 0.

I would say acceptsVoid(0) should be bad as well, but there's a critical use case here, which is Mockito.

verify(list.add(x)).called(1);

verify has to accept void results to have this API. The type of verify should then be

Verification verify(void _) {
  ...
}

And this is a "safe" way to pass around void because we still know it can never be used.

If we made it illegal to assign non-void to void, then

verify(list.toString()).called(1);

would no longer work without using a different signature for verify:

Verification verify<T>(T _) ...

though, its funny to say, this is what we already do, but just for backwards compatibility so that it works on pre-generalized-void VMs.

This I think would be a safe restriction but still can be misused in two ways

// 1: we lifted an unusable value `void` to a usable value `T`!
void printAll<T>(List<T> l) => l.forEach(print);

// 2: we think a void function returns a list rather than populates one!
int lazyStr;
Future<void> populateStr() => lazyStr = await ...;
List<T> toList<T>(T item) => [item];
Future<List> buggy() => populateStr.then(toList).then((x) => x..add("adding to a List<void>, not a List<String>!"))
// this can be even worse but its generally pretty contrived examples to make this go wrong.

As well as the original "funcOk" "funcBug" example before.

None of these examples result in type errors, but they can still result in bugs.

So I think we have good reason for drawing the lines where we've drawn them, but I personally would like to see "void" not be assignable from non-void, and keep the mockito solution as-written. That said, haven't done experiments on how this works in practice.

[MichaelRFairhurst]

something of type void cannot take on any values

This is not true. Something of void can not be used. This implies that it can be any value, as that will be safe since we guarantee it will not be accessed.

Notably, methods with no return statement return null. So void x() {} returns null. But we could safely change that to 0, its an implementation detail, really.

you can return a value from an async method that returns Future

This is an open issue.

According to the analyzer, you can pass "void"-expecting objects into APIs that expect other types, though that is a runtime error in Dart2 (not Dart1)

The reified type of List<void> is List<Object>. So this isn't always a runtime error, you're just seeing assignability checks but they are not guaranteed to crash :( This I think may be fixed later? I'm not sure.

You can pass non-void expecting objects into APIs that expect void objects, with unexpected results:

This is because a generic of type T may use that type T (for instance, in List.toString()) and then later it may be applied as void. This means you can effectively use the void value in generic code. We could only allow void with things like T extends void, perhaps. But that may not always be intuitive either.

[eernstg]

I may be confused, but my understanding and intuition is that void
means nothing, and something of type void cannot take on any values.

I don't think that's a good intuition to have about void in Dart. Dart 2 comes from Dart 1, and Dart 1 never supported that intuition: It has always been true that a function returning T is a subtype of a function returning void (when the parameter types allow it, e.g., when the two function types have identical parameter types). So when you think you're invoking a function returning void it could actually be a function returning T, for any T.

The fact that void foo() {} is correctly overridden by T foo() {} for all T illustrates that the situation is the same for instance method invocations as it is for invocations of first-class functions.

The intuition that does work is that void is a top type (like Object, so a value of type void can be anything whatsoever), but it is marked with the property that "this value should be discarded".

This understanding is supported by the way that Dart doesn't let you
return anything from void-returning methods: ..

It is still possible to justify that based on the understanding that void is a top type whose value should be discarded: return e; in a void function is misleading, because it looks like the value of e will be used, but given that the return type is void it will be discarded (unless the call-site explicitly overrules the "should be discarded" flag using as).

It also doesn't let you read anything from arguments that are explicitly typed void:

Here, the error message explicitly spells out that a value of type void should be discarded, and there's nothing stopping that value from being anything.

For the next example, you're right that we need a correction:

Future<void> foo2() async {
  return 0; // no error (!!)
}

I added a sentence about this situation and a reference to this issue here, where return is being discussed.

You can also pass values to methods expecting void

Right, you're allowed to discard any value. We discussed this, and you could certainly claim that it's equally bad to discard a value by passing it as an actual argument to a function as it is to discard it with return e (in both cases you might mistakenly assume that the value is being used). But the argument why return e is worse is that it will discard the value every time the enclosing function is invoked, and that is a misinterpretation of how the enclosing function works. But when you pass a value like f(e) where f takes an argument of type void, it is (1) an implementation detail for f that it ignores its argument, (2) explicit for anyone looking at the declaration of f that it is intended to ignore its argument (it would be SomeType f(void x) { ... /* x not used here, by design */ ... }). So we are at most misinterpreting a call site, not a function.

you can pass "void"-expecting objects into APIs that expect other types,

This is allowed until we add a 'voidness preservation' analysis (which is mentioned in the generalized void feature specification). Voidness preservation deals with all the situations where a "derived type" can be void, e.g., because we are operating on a List<void> under the statically known type List<Object>. Your second example actually touches on voidness preservation in a slightly surprising way:

void printVoidList(List<void> list) {
  print(list); // Formal parameter type `Object`, no problem.
}

void main() {
  printVoidList(const <int>[0]); // Assign `List<int>` to `List<void>`, no problem.
}

First, note that it was decided at a very early point that void differs from Object only by carrying the "please discard!" flag during static analysis, at run time it is the same type. Also note that there are no soundness issues in using a value of type void, it is purely a developer specified intention that certain values are not meaningful and should be discarded. So there is nothing wrong with the values according to the language semantics.

Hence, it is purely a static property to be void (rather than just being an Object).

In particular, we don't want to generate code for List in such a way that it behaves differently when it has type argument void. So in print(list) we just pass an object of some type (it happens to be List<void>) for a parameter of type Object, and that is allowed. Any object (including a List<void>) has a toString method, and since a List<void> is not behaving differently than a List<Object>, it will proceed and print its elements as usual.

This illustrates that being void is not a security feature, we should not assume anything like "a void value is confidential".

Next, printVoidList(const <int>[0]) is fine, also when we add voidness preservation, because it "indirectly marks the list elements with the should-be-discarded flag", and it's always OK to forget stuff.

However, if you had done something like List<Object> xs = <void>[1]; then it would be a voidness preservation violation.

With that, the first example is also covered: addNumber(list) will be a voidness preservation violation because it involves a cast from List<void> to List<int>. Today, without voidness preservation, it is allowed, but it still fails because List<Object> is not a subtype of List<int> (which is how the type check looks at run time, because void is a static thing).

This leads to situations where you can be completely messing up the types

For the last example, pendingWork.add(work); could be marked as a voidness preservation violation because it uses an actual argument of type Completer<T> where the formal parameter has type Completer<dynamic>, and T can be void.

However, this is a rather draconian rule and in the end we may decide that we won't enforce it. If we don't enforce it then there is a known soundness hole in the treatment of void: We can pass a value of type void into a context where the type void is represented by a type variable X, and then we can assign that value to a variable of type dynamic or Object (because X <: dynamic and X <: Object), and the "void value has then escaped".

Again, we know how to plug this hole, but it's draconian in the sense that it forces type variables without bounds to be treated like void.

The other flagged statement is completeWork<void>(index, 0), and that's OK (it discards 0, and we can forget anything).

So you are pointing out several sharp bends on the road to void, including the fact that we have chosen to introduce a first-order treatment of void now, and add the higher-order part (voidness preservation) later, but I hope that you can use the intuition I mentioned ("a void value can be anything, but you should discard it") to make the whole thing make sense. ;-)

[MichaelRFairhurst]

+Everything that Erik just said!

I may be confused, but my understanding and intuition is that void
means nothing, and something of type void cannot take on any values.

I think you're thinking that void is kind of like Haskell's undefined? In that case, the type you want here is Null. Now, there is one value that can satisfy Null, but its null of course, and that is pretty much the right way of saying "cannot have a value."

import 'dart:async';

void main() {
  Completer<int> completer = new Completer<int>();
  int index = addWork<Null>(completer); // Runtime error: Completer<int> not assignable to Completer<Null>
  completeWork<Null>(index, 0); // static error: 0 is not assignable to Null
  completer.future.then(print); // prints "null"                                                                                                                                                                                                                  
}

This means you can do the following:

List<Completer<Null>> work;

Future<void> valuelessWork() {
  work.add(new Completer<Null>());
  return work.last.future;
}

void main() {
  var x = valuelessWork();
  work.pop().complete(null); // this is the only legal way to complete the work
  x.then((value) {
    print(value); // value is of type void and cannot be used
  });
}

[Hixie]

I think I'm mostly saying two things here:

1. the current state is confusing (sounds like this is a known issue and it'll be resolved in due course)
2. I wish the analyzer and debug/checked mode could help me more with preventing mistakes like the last example of my original comment above. Explicitly assigning a value to a void-declared field or explicitly passing a value to a void argument (whether statically detectable, or catching it at runtime) is very often a subtle bug, and our code will be more reliable if we can catch such cases.

IMHO what mockito is doing is wildly bogus and i have no problem saying that to do that you need lots of explicit casts or pragmas or //ignores or whatever.

[MichaelRFairhurst]

Note: I edited this a bunch since first posting...

How about a lint for assigning to a void value? And a lint for inferring a type parameter of type void?

The latter will require you to use //ignore in many cases with mockito and be hard to write, but the former would be very easy. And these makes sense as a lint, because it isn't a soundness problem, but more like a "you seem to be holding this wrong" problem.

here's what we could/couldn't catch with these two lints.

int returnInt() => 4;
void voidFn() => returnInt(); // won't be caught; its assumed returnInt() must have side-effects.

class Uses<T> {
  void use(T t) => print(t);
}

new Uses<int>(voidFn()); // caught today.
new Uses<void>(returnInt()); // can be caught with lint dart-lang/sdk#57147, otherwise will print 4
new Uses<void>(voidFn()); // won't be caught; will print 4

void use<T>(T t) => print(t);

use<int>(voidFn()); // caught today
use(voidFn()); // can be caught with lint dart-lang/sdk#57148, otherwise will print 4

...

IMHO what mockito is doing is wildly bogus

But I do respectfully disagree here. I'd invite you to consider that what mockito is doing has no soundness issues, produces no bugs, is not surprising to users, is cleaner than the Java version, and is relied upon to work like this in thousands of places. You can say it relies upon something bad, but that does not mean that it itself is bad.

I still think that the type you want here is Null:

void main() {
  Completer<int> completer = new Completer<int>();
  int index = addWork<Null>(completer); // runtime error, +static error with --no-implicit-downcasts
  completeWork<Null>(index, 0); // error, 0 not assignable to Null
}

and I think you should be proud for being one of those rare types of users that is using the type system sufficiently enough to need to use Bottom instead of Top. But those have strong theoretical grounding, so we can't really "fix" them for you if you find it unintuitive (which it is) to know which one to use.

As a general rule of thumb, data coming in will use Bottom when data going out uses Top, and vice versa. Void is a form of Top, and Null is Bottom. So if you would be returning a void value, then you want to accept a Null value.

[MichaelRFairhurst]

my understanding and intuition is that void means nothing, and something of type void cannot take on any values.

As another example of void meaning "anything" and Null meaning "nothing" -- even though void can't be used as anything and Null can -- consider a function that throws. Usually people type it like so:

void throwException() { ... }

This seems like a good idea until you realize that its typesafe to abort the program anywhere.

print(throwException());

^^ this is fine. It won't print, it will throw.

To do this, we use the Type indicating "Nothing." Namely, Null, or Bottom. This is the subtype of all types.

Null throwException() { ... }

Granted, this makes more sense in lazy languages:

return [1, 2, 3, throwException()];

but it still can be useful in dart for the same type of reason:

cache.getOrUse(key, throwException);

Here, if we use "() -> void" then that's not a subtype of "() -> T". But "() -> Null" is for any T.

my understanding and intuition is that void means nothing, and something of type void cannot take on any values.

You can see how this is a better example of "Nothing" than "void." By using Bottom, we can say "this value is usable anywhere" and the reason we can safely say it is because it will never take on any values -- you type a function as return Null to say it never returns.

This is the opposite of saying it returns any value: "void." In that case, it does take/return a value, we just make zero promises about what it is.

So if it never takes/returns a value -> we can promise it does everything. Its a subtype of all types. Because it won't happen.
If it does take/return a value -> we can give no promises about what it does. It is a supertype of all types. And its there, you just can't use it.

Note that if dart gets non-nullable types, then Null will no longer be the Bottom type. We'll probably add a new type named Nothing or something.

[Hixie]

I understand the theory (mostly), but I think you're fighting an uphill battle. "void" simply looks like it means "nothing" (also void. n. a completely empty space.). Writing code like "void foo() {}" feels natural. Writing code like "Null foo() {}" does not. As soon as "void" was a valid keyword, we started using Future<void> over Future<Null> because it just feels more idiomatic and correct, even if it isn't.

We should go with the flow here and just have void work the way people will assume it works anyway.

[MichaelRFairhurst]

I think the lint is still a good approach, because values being thrown away isn't a type error but it is a code smell.

Its still tricky to know where to draw the line, and I think Null just is a useful type whether void does or doesn't do something.

It will be better in the future if we make non-nullable types, and Bottom is called Nothing instead of Null. Then I think people will feel proud of themselves for using the type system to the point of distinguishing Completer<Nothing> from Future<void>, and learning the theory differences, rather than feeling grossed out by having to use the type Null, which I must admit, just feels like a step backwards.

[eernstg]

"void" simply looks like it means "nothing" (also void. n. a completely empty space.)

I think it might be easier to reconcile common intuitions and language semantics by focusing on the other words spelled void: verb 1. NORTH AMERICAN declare that (something) is not valid or legally binding. "the Supreme court voided the statute"; or: void adjective 1. not valid or legally binding.

So when we encounter a void value, we know that it shouldn't be considered valid, and hence there is no other appropriate action than discarding it.