Support for type parameters in constant creations.

[DartBot]

This issue was originally filed by [email protected]

---

The following is not possible in Dart atm:

class Const<T> {
  const Const();
}

class Composite<T> {
  final Const<T> _internal;

  const Composite() : _internal = const Const<T>();
}

Error: The constant creation cannot use a type parameter.

Why do we need this?

---

We have our own RigidList/RigidMap/etc implementation and we'd like to be able to have an empty const constructor that is not <dynamic>.

More

---

Related error: "Arguments of a constant creation must be constant expressions", when you try to use the type parameter and assign it to eg a field.

The underlying issue seems to be that the type parameter is not treated as constant in the const constructor, even though it always (even in normal constructors).

[gbracha]

The assumption that the type parameter is always constant is false.

class Foo<T> {
  bar => new List<T>();
}

which is why we don't allow type parameters as constants. One could seek to liberalize this; it adds complexity to an already complex process, which is why it was not done in the first place.

I think it could be done, but it is a question of priorities; no one has ever had an issue with this particular restriction until now, so we haven't considered it.

---

Set owner to @gbracha.
Removed Type-Defect label.
Added Type-Enhancement, Accepted labels.

[DartBot]

This comment was originally written by [email protected]

---

Could you explain this some more? I'm not sure I understand the example.

I was referring to T being constant within the context of eg Foo<T> or Composite<T>. And with the I mean, that the value of T (a Type) is known and cannot change.

So in my example, for the expression const Const<T>(), the compiler knows what T is at compile time because it knows T = X from the expression const Composite<X>() that instantiates the enclosing constant, and thus it should be able to instantiate const Const<T>() as const Const<X>() like that.

Do I misunderstand something?

Thanks,
 Andreas

[gbracha]

What I was referring to was the statement:

"the type parameter is not treated as constant in the const constructor, even though it always (even in normal constructors)".
So, no it is not always a constant. In the example, T in the expression new List<T>() is only know at run time.

Now, one could introduce rules that allowed the use of type parameters in const object creation under certain restrictions, which is what I believe you are asking for. In terms of the specification, that would amount to adding types as "potentially constant" and then insisting that in any type arguments in a const object creation expression are restricted to type literals or parameterized types whose arguments follow the same restriction recursively.

Now it's not that hard to specify, but the pity the poor souls who implement this. Reification of type parameters is a very complicated part of the machinery, especially when it interacts with other features like mixins. Adding constants to this is not something to be undertaken lightly.

Of course this can be done. But as I say, it is a question of priorities. In terms of bang for buck, it carries relatively little bang for a surprisingly large amount of bucks.

[DartBot]

This comment was originally written by [email protected]

---

Ah thanks! I understand it now. Yeah, I was pretty much asking for propagation of constness in the case of const constructors.

[DartBot]

This comment was originally written by [email protected]

---

Thanks Gilad. FWIW, here's why we care about this issue: it forces us to choose between

1. Incomplete runtime generics;
2. No const collections; which means no defaults.

To catch bugs we strongly prefer to have complete runtime type parameters so that collections are able to do type checking on elements. Unfortunately, missing type parameters are 'viral': they can be silently propagated via methods like toList.

List<String> createFooList(List<String> list : []) {
  list.add('foo');
  return list;
}

var list = createFooList();

// much later, with .toList and various other things in between...

list.add(103); // whoops! should be caught at runtime in checked mode

Currently I'm thinking we will go with #­2, on the grounds that catching bugs is more important than the (admittedly attractive) convenience of const collections. (And, of course, other parameterized types, but collections are the primary use case).

[DartBot]

This comment was originally written by [email protected]

---

I think the issue is in general that constness cannot be forwarded.

I had totally forgotten that even

class X {
  final x;
  const X(this.x);
}

class Y {
  final a;
  const Y(x) : a = const X(x);
}

does not work.

I think the only way out of this for now is to just avoid using const at all because it does not seem very 'complete' in the mathematical sense :(

[kevmoo]

Marked this as blocking #22431.

[munificent]

I think this is a duplicate of #25572.