member of const object should be member as well

[DartBot]

This issue was originally filed by halfjui...@gmail.com

---

For example, the following example should work. But it's not right now in the IDE.

class Config {
  final String name;
  const Config(this.name);
}

class App {
  static const config = const Config('hello');
}

@RandomAnnotation(fieldNeedsToBeConst = App.config.name)
class Foo {
}

[DartBot]

This comment was originally written by @zoechi

---

What Dart version do you use?

[lrhn]

While I agree that it (or something similar) should work, it's not currently valid Dart code.

Reading a property of a const object is not itself a compile-time constant expression. That means that "App.config.name" is not a compile-time constant expression due to the ".name", and it can't be used as parameter to the const expression @­RandomAnnotation(...).

So, working as intended. I'll mark this as an enhancement request for the language.

---

Removed Type-Defect label.
Added Type-Enhancement, Area-Language, Triaged labels.

[rkj]

Why reading a property of const object is not itself a const expression? Any similar syntax to achieve the same? This makes impossible to do a case switch on a ProtobufEnum (https://www.dartdocs.org/documentation/protobuf/0.5.0%2B1/protobuf/ProtobufEnum-class.html), and that makes a lot of sad if/else clauses...

[lrhn]

I can't say why it isn't valid - the short answer is "because it's not in the spec".

On possible reason for rejecting it is that it will break the getter/field equivalence.
Currently fields are specified as being accessed through implicit getters, and all o.foo accesses are getter calls. That means that you can replace a field with a getter and vice versa without changing the way a class can be used.

If you can read final fields of a const object as a const expression, and you can't read a getter as a const expression (which you definitely can't, const expressions never execute code), then the field/getter equivalence is broken, and you can't change a field to a getter any more.

That's at odds with the design of the language, so we don't want to add that, even if it can be convenient occasionally.

A solution that has been suggested is to allow const instance fields. They are like final fields except that they can be read as compile time constants, and this way the class author has to explicitly opt in to the field being const. After that, it might even be possible to add const getters - getters with bodies that are potentially constant expressions, but with access to const fields of the same object - but that requires a way to avoid recursion.

[munificent]

Closing as a duplicate of #16547. This issue describes the problem while that one describes a potential solution.