Introduce `undefined` type or keyword to differentiate intentional absence of value and uninitialized state

[nathnaeld]

The current use of null for optional parameters in methods like copyWith can lead to ambiguity. Specifically, null is used to signify "leave unchanged", making it difficult to explicitly set a field to null. This inconvenience complicates the handling of optional fields.

Introduce an undefined, nil, or similar type or keyword to represent omitted values, distinct from null.

For example:

class User {
  final String? name;
  final int? age;

  User({this.name, this.age});

  User copyWith({
    String? name, 
    int? age,
  }) {
    return User(
      name: name == undefined ? this.name : name,
      age: age == undefined ? this.age : age,
    );
  }
}

void main() {
  User user = User(name: 'John', age: 30);

  User newUser1 = user.copyWith(name: 'Jane'); 
  print(newUser1);
   // Output: User(name: Jane, age: 30)

  User newUser2 = user.copyWith(name: null); 
  print(newUser2); 
   // Output: User(name: null, age: 30) 
}

[mmcdon20]

Similar idea to #3680.

[lrhn]

Not a new idea. It has been discussed before, and having a first-class undefined type just pushes the problem one turtle further down, and having a non-first-class undefined type makes it effectively not really a type anyway. Having an undefined value that doesn't have a type is going to break a lot of useful invariants (like "values have types").

Not going there. A specific operation to check the initialization state of a late variable, like #3680, won't introduce any new types or values, so it's much more palatable. Other similar ways to work around the issue without reifying the lack of a value as, well, a value, could also work.
But undefined is right out.

[mateusfccp]

Duplicate of #877.