const at the top level of a structure should propagate down

[alan-knight]

I have some large objects which are constant. As it stands, writing one of these out requires 22 occurrences of the word "const", one for every field (which isn't a string literal or number, because those are implicitly const and it's an error to write it explicitly).

It is not legal to write a const constructor call, literal Map or literal List containing non-const expressions. So it seems unnecessary to require a const annotation on the individual pieces. They are required to be const, so we should just enforce that they are without requiring the developer to also spell it out. That is to say, instead of having to write

var list = const [ const ['a'], const ['b'], const ['c']];

I should be able to write

var list = const [ ['a'], ['b'], ['c']];

there the outer const also applies to the inner lists. And the same for maps and const constructor invocations.

[madsager]

Added Area-Language, Triaged labels.

[DartBot]

This comment was originally written by @seaneagan

---

I really like this. The main problem is what do you use instead of "const" for the nested constructor calls? Using "new" wouldn't look right. Using nothing is better, but then it isn't consistent with constructor calls elsewhere. I think this is yet another reason to remove the "new" keyword (and factory constructors as they would no longer be needed).

This would really help out with making annotations more terse and readable:

@SomeAnnotation(const Foo(const Bar(), const Baz())

@SomeAnnotation(Foo(Bar(), Baz())

[lrhn]

You can change const expressions without changing non-const constructor calls.
E.g., make "const" in expression context not be an construct similar to "new", but rather a marker that makes the following expression be interpreted in a slightly different way: all maps and lists are constant, all function calls are const constructor invocations, and only some operators are allowed.
It would amount to the same as the suggestion, but const expressions would then not have to use the same grammar as non-const expressions.
And metadata annotations would simply use the const expression syntax by default.

[DartBot]

This comment was originally written by @seaneagan

---

What I meant to say is that bare (without "new" or "const") constructor calls would look weird inside these proposed "const" expressions... unless they were the norm in the language, as would be the case if "new" were removed.

[DartBot]

This comment was originally written by @seaneagan

---

Then there would be no special syntax needed inside of "const" expressions, it would just implicitly apply "const" modifiers to everything.

[gbracha]

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

[gbracha]

Issue #3974 has been merged into this issue.

---

cc @sigmundch.

[lrhn]

Issue #4803 has been merged into this issue.

[justinfagnani]

This would be great in metadata annotations where we don't require const for the constructor, but then require it for arguments.

[DartBot]

This comment was originally written by @seaneagan

---

Example user confusion here:

http://stackoverflow.com/questions/20223354/custom-metadata-with-unknown-parameter-length

[kasperl]

Removed this from the Later milestone.
Added Oldschool-Milestone-Later label.

[lrhn]

Issue #20021 has been merged into this issue.

[kasperl]

Removed Oldschool-Milestone-Later label.

[zoechi]

I guess the link provides more value here than in #24620. I was sure I have seen the proposal but wasn't able to find it.
https://github.com/lrhn/dep-const/blob/master/proposal.md

[eernstg]

This feature is now an accepted part of Dart 2. The feature specification implicit-creation.md gives the details, but the following is a good starting point:

For instance creation expressions we have chosen to use const whenever possible,
and otherwise new.
...
For composite literals we have chosen to implicitly introduce const whenever it is
required by the context.

So C(42) is a constant expression if the relevant C constructor is const (even in cases where the context does not require a constant expression), and const xs = []; makes [] a constant list, but var xs = []; makes [] a non-constant list.