Let types declare default values, and make them available on type variables.

[Silentdoer]

please consider following code, and it's comment.

class Foo<T> {
// T k = default(T);
  T k;

  int m;

  // will tips: Non-nullable instance field 'k' must be initialized.
  // but if k is T?, and Foo<int?>, k's type will be int?? is very odd.
  // so i think may be support default keyword, then T k = default(T), and not allow T? k statement.
  Foo(int a, T b) {
    this.m = a * 2;
    this.k = b;
  }
}

[Silentdoer]

if T is a complex class, like:

class Stud {
  int age = 12;
  String name = '';
  Stud(int age) {
    this.aget= age;
  }
  // not allow T? prop
  default Stud(3);  // and if T is Stud, then default(T) is Stud(3)
}

[lrhn]

The request is that a type can declare a "default value" (default Stud(3); above for the Stud class), and that you can ask for the default value of an type as default(T).
I'm assuming that the default e; expression is evaluated on each access, so it's effectively a static getter.

Here it's requested that this works on a type variable.

That's a very tricky request. If not all classes declare a default value, and default values are clearly not inheritable since a superclass value is not a subclass value. Then it's not clear how we can allow the operation to work on a type variable which can assume any subtype of the bound, even Never (which cannot have a default value).

We'd have to make it part of the type parameter constraint: foo<T extends Something default> which means that only types with a default value can be used. If we do that, we could perhaps also allow you to specify any static member that the type must have, and then just use <T extends Something { static T get defaultValue; }> as declaration, no need for a special declaration.
In either case, it's not a normal type constraint, it's not trivially satisfied by all subtypes. That means that you can only use literal types satisfying the constraint, or type variables also declared to satisfy the constraint.

I guess all nullable types will have null as default value, and we can find default values for num/String/bool without issues.
I'm not sure I'd want to make List<T> have a growable <T>[] as default value.

[eernstg]

About types like int??: It is certainly possible to encounter such types. It is possible if we can pass a nullable type like int? as an actual type argument to a type parameter X, and we can use a type like X? in the scope of X, and those things are too fundamental to take away. Types like int?? are normalized in some situations, cf. normalization.md, and otherwise they are handled via recursion in subtype rules.

[Silentdoer]

may be can support class Foo<T is! nullable> {} , then user can not use Foo<someType?>

[Silentdoer]

Types like int?? are normalized in some situations

i can't think out what's the situation should use int?? type..

[leafpetersen]

may be can support class Foo<T is! nullable> {} , then user can not use Foo<someType?>

@Silentdoer this is already expressible via class Foo<T extends Object> {}.

Types like int?? are normalized in some situations

i can't think out what's the situation should use int?? type..

It arises accidentally in some places, and is harmless. The type system treats it as equivalent to int?.