With constant maps, and to a lesser degree lists, it's sometimes relevant to do refer to a constant entry of such a map.
I suggest allowing expressions on the form a[b] as compile-time constants when either a is a List or String and b is an integer, or a is a Map and b is a String.
Makes sense to me (assuming a and b are constants).
_Set owner to @gbracha._
_Added Accepted label._
_Added this to the Later milestone._
_Removed this from the Later milestone._
_Added Oldschool-Milestone-Later label._
_Removed Oldschool-Milestone-Later label._
Issue #8885 has been merged into this issue.
+1
Here's a concrete use case where this would be quite nice. Not entirely fleshed out, but it seems like it would be workable.
With Intl, you write the message text directly in the code. e.g.
get hello => Intl.message('hello world', desc: 'A greeting to the world from a very simple program');
The desc parameter is only used at message extraction time, and the library is written so that dart2js knows it can completely remove it during compilation. But the actual text is used as a lookup key for the translation, so we can't remove it. And that wastes a bunch of space, because we have the English text included in every version, even if it's never going to be displayed.
We could avoid this by instead having you write the English text in a separate resource file, create some ID for it, and use that in the code. But that's a lot worse experience.
However, I can compute some known value based on the text, and probably do for translation purposes. And if I was able to de-reference a const, then it seems like I could do something like
get hello => Intl.message('hello world', desc: 'A greeting to the world from a very simple program').toString();
...
class Intl {
const Intl.message(String text, String desc): _id = messageHashes[text];
and have generated code
const messageHashes = {
'hello world' : 0xabcdefg,
}
And if the system allowed me to do that dereference in an initializer, and was smart enough to know that the messageHashes map was never referenced from anywhere except a const constructor and could be discarded, then we could optimize away all that English text and just store ids.
Hi! Any progress on this? I think it's kinda reasonable to expect a const string on a const Map to be const.
It's been awhile since this feature has been talked about -- any updates on the progress?
There are no current plans to extend the scope of compile-time constant expressions.
When we do something in this context, it's driven by necessity from other changes to the language, not a wish to actually make more expressions compile-time constant.
Incrementally adding small syntax extensions to the constant rules is not something that is giving the most bang for the buck. I think that, with the current priorities for Dart, a complete revamp of the constant sub-language and behavior is worth investigating, rather than incrementally growing the existing one on a case-by-case basis.
Most helpful comment
Hi! Any progress on this? I think it's kinda reasonable to expect a const string on a const Map to be const.