Warn went creating `Set<void>`

[jamesderlin]

Creating collection literals from void surprisingly doesn't generate any runtime errors nor analysis warnings:

void voidFunction() {}

void main() {
  var list = [voidFunction()];
  var set = {voidFunction()};
  var f = () => {voidFunction()};

  print(list); // Prints: [null]
  print(set); // Prints: {null}
  print(f()); // Prints: {null}
}

I'm confused why since my understanding was that void values are not allowed to be read.

I'm not sure if this somehow is intentionally not an error, but at a minimum, I think that we could warn if creating List<void> or Set<void>. Those types don't seem like they'd ever be useful. Set<void> is particularly bad since I've observed at least one person using (arg) => { doSomething() } when they meant either (arg) => doSomething() or (arg) { doSomething() }. (Such a lint wouldn't help if doSomething() returned a non-void value, of course ,but I don't know what could be done about that other than requiring => { ... } to be => <T>{ ... } if a Set is actually desired.)

I tried this with version 2.13.4 of the Dart SDK.

[pq]

Void collections are surprising and feel probably like a mistake but I'm not sure if there's a nuance I'm missing.

/cc @srawlins @eernstg

[srawlins]

I thought about this a bunch, and I think this could be worthwhile, given one restriction.

I think in general Set<void> is not something worthy of linting. You might be gathering up the results of function calls, all of which return void, or maybe awaiting Future<void> or something.

But I think @jamesderlin has a really good find here with set literals, of void. This does seem like an easy mistake to make (=> { ... }).

(I once did a survey of all of the uses of noSuchMethod that I could find. The vast majority were noSuchMethod(_) => throw Unimplemented(); or noSuchMethod(_) {}. However there was also a comically large number (I think the 3rd most prevalent) of this implementation: noSuchMethod(_) => {}; which is definitely an accident. Because noSuchMethod returns dynamic, there's nothing to flag this goofy typo.)

[srawlins]

So, on the one hand we could go extremely specific and report:

• a set literal,
• with exactly one element (which is not a spread),
• whose parent is a function expression body (=>)

Or go broader from there, if there is reason or evidence to capture other things.

[jamesderlin]

You might be gathering up the results of function calls, all of which return void, or maybe awaiting Future or something.

Ah. I think more specifically the reason to allow List<void> and Set<void> is if they're actually used as List<T> and Set<T> in some other generic function where T could void. (I keep forgetting about that corner case.) That seems reasonable (although I'm still surprised that it works).

[jamesderlin]

How does Set<void> work anyway? How is it legal to call .hashCode on void elements? Is there some special check for a void element type?

Related: someone came up with this hack: https://stackoverflow.com/a/71648601/

[eernstg]

I think the specification section about 'Void Soundness' is relevant to this discussion. The source is here. The (much more readable) PDF is here, but we can't link to a location in a PDF, so with the PDF you need to search for 'Void Soundness'.

The static analysis of Dart supports maintaining the property that the value of an expression whose static type is void is not used. However, there is no such protection when it comes to indirect usages. So even in the case where the value of a given type variable X is void, we can freely use that value as long as it is typed X.

Similarly, a List<void> or Set<void> is assignable to a variable of type List<Object?> respectively Set<Object?>, which means that we can "forget the voidness" of the elements without incurring a compile-time error.

void foo<X>(X x) => print(x);

void main() {
  void v = 1;
  foo(v); // Prints '1'.

  Set<void> sVoid = {1};
  Set<Object?> sObjectQuestion = sVoid;
  for (var v in sVoid) {
    print(v); // Error: `v` has type `void`.
  }
  for (var o in sObjectQuestion) {
    print(o); // OK.
  }
}

Function types is another case where void can occur as part of a type, and there is no attempt to protect the function type as such against assignments to or from other function types (or other types in general) where the type void doesn't occur. In other words, the protection against using "void values" only works in the direct usage case, not any of the indirect ones.

The reason for this is that (1) there is no soundness issue with violations (there's nothing inherently wrong with an object obtained as the result of evaluating an expression of type void, it's just specified by the developer that we shouldn't use that object, because it isn't intended to be usable for any specific purpose); and (2) a strict enforcement of the rule that "the value of an expression of type void cannot be used" would require extra support at run time. The language team decided very quickly that it would not be justified to make all programs run more slowly in order to enforce that kind of constraint.

So the reason why print will print the elements of a Set<void> without complaints is that the Set<void> is passed to a parameter of type Object?, so there's no problem calling its toString, and the toString implementation runs in a scope where the type variable E can have the value void, but there is no enforcement of any void related constraints even in the case where the value of E is actually void. Similarly for hashCode.

Returning to the core topic of this issue, I think we can't easily do anything about the case where a type variable X has the value void, and the body of a class or similar construct uses expressions of type X in ways that a plain void wouldn't admit. But I also think that we could introduce a simple kind of void soundness, perhaps as an updated version of #57770.