Dart's odd problems

[seha-bot]

First off I would like to apologise because this is not an issue with invariant_collection. I am writing here only because I don't know how to contact you ':-)

Your attention to writing safe and readable code and your contribution to Dart made me reach out to you for assistance.
I am collecting examples of "odd" Dart code for my presentation.

What do I mean by "odd"?

Odd code is code which is either undefined or unclear. Undefined is self-explanatory, but I doubt there is anything undefined in the Dart standard (you tell me :D). Unclear is code which can confuse the reader and induce him to thinking it does thing X, when in reality it does thing Y.

Motivation

I am a member of a discord server focusing on embedded engineering and it features an "odd problems emporium" channel. People post odd code and without using a compiler you need to explain what that code does.

Example:

/* C99 */
int main(void) {
    int i = 1;
    return i / i++;
}

What does this program return? Solution is that this is UB as there is no sequence point.

What have I collected so far

No real type safety

dart-lang/sdk#55021

Default parameters are allowed to be overriden

class Foo {
  int bar([int? baz = 0]) {
    return baz!;
  }
}

final class Bar extends Foo {
  @override
  int bar([int? baz]) {
    return baz!;
  }
}

void main() {
  Foo foo1 = Foo();
  Foo foo2 = Bar();
  print(foo1.bar());
  print(foo2.bar());
}

the existence of covariant

Return values of methods are allowed to be specialized, while for parameters you need covariant.
I will present this as "odd" because most people will be confused after I show them these two examples in succession:

Slide 1:

abstract class Foo {
  Foo bar();
}

final class Bar extends Foo {
  @override
  Bar bar() {
    return this;
  }
}

Slide 2:

abstract class Foo {
  void baz(Foo foo);
}

final class Bar extends Foo {
  @override
  void baz(Bar bar) {}
}

void is of type Null and has a size

void main() {
  List<void> foos = <void>[];
  foos.add(print("0"));
  foos.add(null);
  for (final e in foos.cast<Null>()) {
    print(e);
  }
}

Pattern matching is falsely non-exhaustive

#3633

Conditional member access operator discards the assignment operations

final class Foo {
  int i = 0;
}

void main() {
  Foo? foo;
  int i = 0;
  foo?.i = ++i;
  print(i);
}

Note

I am not trying to get anyone to dislike Dart and all of these "issues" have a valid reasoning behind their existence.
Thank you for reading this and I hope you can provide some more examples of oddity in Dart. Also, would you like to say something so I can put it as a quote in the presentation?

Cheers

[eernstg]

Hi @seha-bot, thanks for the input!

It's always good to have a debate about things that could work in a different way. Many of these points are well taken!

In some other cases, however, I think it would be useful if you could be a bit more precise, as mentioned in some cases below.

Now for some responses:

No real type safety

Dart does maintain heap soundness (that is, a variable with declared type T has a value of a type S such that S is a subtype of T, which includes the case where S == T). It is also ensured that every expression of static type T will evaluate to a value whose run-time type is a subtype of T.

What you're reporting in the linked issue dart-lang/sdk#55021 is that type inference may provide some type arguments that are determined by the context rather than the inferred expression itself. I don't think it's quite fair to say that this shows 'no real type safety'. A more factual phrasing could be "Dart type inference gives priority to the context type; please note that this can result in more general inferred type arguments than you expect".

If you're not happy about the inferred type arguments you can always provide different type arguments manually.

Default parameters are allowed to be overridden

This is a good one! It used to be a warning, but it was removed. Consider voting for dart-lang/sdk#59293 if you wish to restore the diagnostic message about this situation.

the existence of covariant

Return values of methods are allowed to be specialized, while for parameters you need covariant.
I will present this as "odd" because most people will be confused after I show them these two examples in succession:

This is a very useful distinction. Specialization of a return type is a standard mechanism, and completely type safe (several languages support this), and there is no need to flag locations where this kind of specialization occurs.

Specialization of a formal parameter type (which requires covariant) is a very special mechanism (no pun intended ;-). Whenever this mechanism is used, there is a potential for run-time type errors. So you should only use this mechanism if you know what you're doing, and you actually need it (which is the reason why it must be show explicitly be an occurrence of the keyword covariant).

Note that using this mechanism is very similar to putting a type cast at the beginning of the method:

class A { void m(num n) {...}}
class B extends A { void m(covariant int i) {...}

// Nearly the same thing:
class A { void m(num n) {...}}
class B extends A { void m(num n) {
  int i = n as int; // Throws a type error unless `n` is an `int`.
  ...
}

These two approaches are equally unsafe, but the version that uses covariant may be considered more "civilized" because it announces the risk explicitly in the signature of the method.

void is of type Null and has a size

OK, void is odd. ;-)

The type void is a top type. It is not true that "void is of type Null" (actually, every type including void can be evaluated to an object of type Type, so in that sense void is of type Type).

The value of an expression of type void can be anything whatsoever (that's simply the mean of "void is a top type"). For instance, void x = 42; is fine, and so is `void x = [true, #foo, 3.14, "String"].

Any object has a size (not that you can easily find it, but it will occupy a certain amount of storage in the heap), and that doesn't change just because that object is obtained as the result of evaluation of an expression of type void.

Pattern matching is falsely non-exhaustive

The fact that pattern matching exhaustiveness analysis doesn't recognize every situation where a switch is actually exhaustive is unavoidable. It may of course be possible to improve on the current algorithm, in particular in the example of dart-lang/sdk#58844, but we can't expect to achieve completeness in this area, for any language with pattern matching.

Conditional member access operator discards the assignment operations

This is definitely working as intended. Do you actually want the semantics of o?.x += e; to be such that e is evaluated even in the case where o is null? In that case you can use var tmp = e; o?.x += tmp;.

[seha-bot]

Thank you @eernstg for your thorough reply.

All of those cases have a valid reasoning for their existence. My goal is just to point them out because some may seem unintuitive for people who haven't come across them.

I was wondering if you, perchance, have any odd cases to show me, so I can put them in my presentation?

Thank you again!

[lrhn]

There is always the associativity of cascades and conditional expressions.
We allow []..add(2) as a way to create a list similar to [2], but what will var list = empty ? [] : []..add(2); do?

And the ability to ignore final/base/interface modifiers inside the same library. (Can't include sealed as surprising, even if it behaves the same, it simply wouldn't work any other way.)

Maybe the syntax for conditional imports:

import "file1.dart" if (dart.library.io) "file2.dart";

(It's more readable when not on the same line.)

Implicit const contexts in some places, but not others:

const c = []; // No problem, value is automatically constant.
class C {
  final c = []; // Error, value must be constant.
  final x;
  const C({this.x = []}); // Error, default value must be constant.
}

(The default value not being implicitly constant was deliberate. The other one was probably a good idea, but was mostly due to being forgotten in the list of constant contexts.)

[seha-bot]

Thank you so much! This is very helpful!
Exactly the stuff I've been looking for. These are all quite odd.

[eernstg]

These are all quite odd.

😃

Here are some other cases:

Web-numbers and native numbers differ: https://dart.dev/guides/language/numbers.

The upper bound algorithm may choose a very general type in some cases: someBoolean ? <num>[] : <int>[].map((x) => x) has type Object, not List<Object>. See https://github.com/dart-lang/language/issues?q=is%3Aopen+is%3Aissue+label%3Aleast-upper-bound. Note that #1618 is being implemented (and it is almost certainly going to be included into the language), and that's going to be a radical improvement on the upper bound algorithm.

The fundamental properties of void may be surprising to many developers: An expression of type void can yield any object whatsoever (in that sense void is the same as Object?), but it's a compile-time error to use that object (it must be discarded). There are some exceptions (e.g., myVoidExpression as T is allowed for any type T), but they should basically only be used to compensate for bad design choices elsewhere in the software (somebody wrote the wrong return type somewhere, but I know I need to use this object).

Some details about void may be surprising, too, e.g., assignment from void to void is OK: void x = print('Hello');, but then you basically can't use x.

Compile-time constants (known as constant expressions): A tiny, very specialized sublanguage of Dart. Proposals about where and how to extend this sublanguage are coming up again and again, and it's very resource intensive to do it. So you may be surprised about what is expressible and what is not expressible as a constant expression, and if you can't express a specific thing then you may be stuck, with very little hope that it will be made possible in the next few versions of Dart.

It is allowed to omit type arguments in type annotations (such as the declared type of a variable or a formal parameter, or a function return type), and they are then chosen by instantiation to bound. This means that List xs = []; is the same thing as List<dynamic> xs = <dynamic>[];. This can cause some subsequent expressions to have the type dynamic, which could again mask various errors. In contrast, constructor invocations and collection literals will have their type arguments inferred; for instance, List<int> xs = []; means List<int> xs = <int>[];. This means that you shouldn't omit type arguments in type annotations, but it's OK to leave them out (if inference succeeds) in expressions.

?? expressions may need parens: In the expression myExpression ?? (throw "Failed"), the parentheses cannot be omitted.

Singleton records need a comma, like (1,), whose type is (int,).

[seha-bot]

I had no idea some of these existed 😮

Constant expressions should definitely be worked on some more as they are very useful.
Not only did you help me for the presentation, but I learned a lot about the language in the process.

I have one question about Dart program termination:
When does dart decide to exit the program?

Consider these two examples:

In this example all asynchronous tasks are finished before exiting:

void main() {
  print("start");

  () async {
    int i = 0;
    while (i++ < 0xFFFFF) {
      await null;
    }
    print("done async");
  }();

  print("done");
}

In this example the program finishes without main ever returning:

void main() async {
  Future<void>? future;

  future = () async {
    await null;
    await future;
  }();

  print("start");
  await future;
  print("done");
}

This seems like a contradiction, but I might not understand how tasks are created and evaluated in Dart.
Dart runs on a single thread (isolate) and manages asynchronous tasks similarly to an operating system.
Other programming languages terminate all tasks when main returns, or when exit() is called, but this doesn't seem to be the case here.
So when does Dart decide to terminate?

Bonus question:
If I write return future; instead of await future; inside the closure I get a stack overflow which is expected. Why doesn't the stack overflow when awaiting it?

Thank you!!!!

PS. I will close this issue when I finish my presentation which is on Monday.

[lrhn]

When does dart decide to exit the program?

In a browser: When you navigate away from the page.

Native: When there's nothing left to do (in the main isolate).
That means the event queues are empty, there are no scheduled times, open receive ports or other active system operations that can trigger a new event.

Which can lead to a surprising exit when you'd think the program was blocked at an async await.

void main() async {
  try {
    await Completer().future;
  } finally { 
    print("done");
  }
}

This looks like it would block at the await of a future that nobody will ever complete, but an await gives control back to the event loop, and the event loop is empty, so the program just exits.

Your second example is like this. The future reopened by your async function call is awaited inside that function.
That means the function execution is suspended until the future completes. The future won't complete before the execution completes.
That's a deadlock.

But it's a passive deadlock, with nobody actually scheduled to do anything. Just a callback put on a future which never gets called, and the program ends because nobody is doing anything.

(Also, you shouldn't get a stack overflow. Returning a future should await it inside the function, giving you a deadlock. It's not implemented correctly, though.)

[dgreensp]

I just want to say that, while I've been using Dart for a month and run into tons of odd or unexpected behavior, I'm really happy that methods are checked with proper variance, following the Liskov Subsitution Principle (that is, the return type of a method should be a subtype of the overridden method's return type, while argument types should be supertypes). TypeScript, for all the increased strictness that has been added over the years, still does not, and cannot, do this checking on method overrides! It's odd to me to complain about type "unsafety" and then turn around and complain about, literally, type safety. The "covariant" keyword is shorthand for a downcast that is checked at runtime. It's just an extra feature (that I'm not sure if I'll ever use, but it's there).

Oh, I'm also super grateful that Dart infers method argument types from the super method, because TypeScript does not do that, and it saves a bunch of typing!

A huge limitation of Dart's generics that TypeScript doesn't have is that class type parameters are always covariant. So you can do this, with no compile-time error, even though it's not sound:

abstract interface class Printer<T> {
  void print(T t);
}

void printStringWithIntPrinter(Printer<int> p) {
  final Printer<Object> q = p;
  q.print("hello");
}

(In fairness, TypeScript requires some coaxing sometimes when it comes to variance, but they've added in and out keywords.) It's kind of impressive that Dart catches the above at runtime, though, because TypeScript would never do that (it throws away the types after checking and does not use them in "compilation").

In reference to dart-lang/sdk#55021, the fact that type parameters have runtime values (based on compile-time type inference) is pretty unusual in Dart, and I'm still getting used to it. In theory, it has some advantages, particularly around enforcing "runtime soundness." The inferred type parameters seem to be poor, in practice, because of "prioritizing" (only looking at) the context type.

The fact that casting a List always requires allocating a new object is an example of something that's been hard to get my head around. For example, if I have a List of FutureOr<T>, and I verify that none of the elements are Futures, I would expect to be able to do one (unsafe) cast to List<T> and keep using the same List object, as I would do in TypeScript. Or if I have a List<Object> and I check that every element is a String, I'd like to be able to cast it to a List<String>. In Dart, a List<Object> is a different thing at runtime than a List<String>, and the former can never be substituted for the latter. You have to either copy the list over, or wrap it (using list.cast), both of which have runtime overhead. It's not the end of the world, but it's a big shock coming from languages that erase type parameters during compilation.

[Levi-Lesches]

I believe type arguments are reified during runtime, so they're definitely different from other languages which erase them at compile time.

As for variance, see dart-archive/linter#753 and dart-lang/sdk#57494

[munificent]

It's kind of impressive that Dart catches the above at runtime, though, because TypeScript would never do that (it throws away the types after checking and does not use them in "compilation").

...

The fact that casting a List always requires allocating a new object is an example of something that's been hard to get my head around. For example, if I have a List of FutureOr<T>, and I verify that none of the elements are Futures, I would expect to be able to do one (unsafe) cast to List<T> and keep using the same List object, as I would do in TypeScript. Or if I have a List<Object> and I check that every element is a String, I'd like to be able to cast it to a List<String>.

These are basically the two sides of one coin. We can defer some soundness checking to runtime because we have access to the reified type arguments of the object at runtime. (It also means that runtime type tests like is List<int> mean what they say.) But the cost for that is that if you want to change that reified type argument, you have to create a new object.