www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - non-constant expression ["foo":5, "bar":10, "baz":2000]

reply Paolo Invernizzi <paolo.invernizzi no.address> writes:
This is stated in documentation [1]:

immutable long[string] aa = [
   "foo": 5,
   "bar": 10,
   "baz": 2000
];

unittest
{
     assert(aa["foo"] == 5);
     assert(aa["bar"] == 10);
     assert(aa["baz"] == 2000);
}

But results to:

    Error: non-constant expression ["foo":5L, "bar":10L, 
"baz":2000L]

Known bug?
If yes, Is there the need to emend the documentation, till the 
bug is open?
---
/Paolo
Nov 26 2016
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Saturday, 26 November 2016 at 17:37:57 UTC, Paolo Invernizzi 
wrote:
 This is stated in documentation [1]:
What's the link? This is a known limitation, it has never worked. The docs should reflect that, though some day, it might start working.
Nov 26 2016
parent Paolo Invernizzi <paolo.invernizzi no.address> writes:
On Saturday, 26 November 2016 at 19:57:21 UTC, Adam D. Ruppe 
wrote:
 On Saturday, 26 November 2016 at 17:37:57 UTC, Paolo Invernizzi 
 wrote:
 This is stated in documentation [1]:
What's the link? This is a known limitation, it has never worked. The docs should reflect that, though some day, it might start working.
Sorry, I forgot to past it in the previous post: here it is. https://dlang.org/spec/hash-map.html#static_initialization -- Paolo
Nov 27 2016
prev sibling parent reply John Colvin <john.loughran.colvin gmail.com> writes:
On Saturday, 26 November 2016 at 17:37:57 UTC, Paolo Invernizzi 
wrote:
 This is stated in documentation [1]:

 immutable long[string] aa = [
   "foo": 5,
   "bar": 10,
   "baz": 2000
 ];

 unittest
 {
     assert(aa["foo"] == 5);
     assert(aa["bar"] == 10);
     assert(aa["baz"] == 2000);
 }

 But results to:

    Error: non-constant expression ["foo":5L, "bar":10L, 
 "baz":2000L]

 Known bug?
 If yes, Is there the need to emend the documentation, till the 
 bug is open?
 ---
 /Paolo
Known bug. If you need a workaround, initialising the variable at load-time with `static this` should help in some cases.
Nov 27 2016
parent reply Paolo Invernizzi <paolo.invernizzi no.address> writes:
On Sunday, 27 November 2016 at 22:25:51 UTC, John Colvin wrote:
 On Saturday, 26 November 2016 at 17:37:57 UTC, Paolo Invernizzi 
 wrote:
 This is stated in documentation [1]:

 immutable long[string] aa = [
   "foo": 5,
   "bar": 10,
   "baz": 2000
 ];

 unittest
 {
     assert(aa["foo"] == 5);
     assert(aa["bar"] == 10);
     assert(aa["baz"] == 2000);
 }

 But results to:

    Error: non-constant expression ["foo":5L, "bar":10L, 
 "baz":2000L]

 Known bug?
 If yes, Is there the need to emend the documentation, till the 
 bug is open?
 ---
 /Paolo
Known bug. If you need a workaround, initialising the variable at load-time with `static this` should help in some cases.
Thank Joan, The point is that I was trying to avoid some cycle between modules, detected by 2.072. This bug leads to pollution in the use of static this only to workaround the limitation... -- Paolo
Nov 28 2016
parent reply Era Scarecrow <rtcvb32 yahoo.com> writes:
On Monday, 28 November 2016 at 09:06:34 UTC, Paolo Invernizzi 
wrote:
 The point is that I was trying to avoid some cycle between 
 modules, detected by 2.072. This bug leads to pollution in the 
 use of static this only to workaround the limitation...
Wasn't someone working on a Associative Array static type that could be created at CTFE and run at runtime?
Nov 28 2016
parent reply HuskyNator <HuskyNator protonmail.ch> writes:
On Monday, 28 November 2016 at 14:41:44 UTC, Era Scarecrow wrote:
 On Monday, 28 November 2016 at 09:06:34 UTC, Paolo Invernizzi 
 wrote:
 The point is that I was trying to avoid some cycle between 
 modules, detected by 2.072. This bug leads to pollution in the 
 use of static this only to workaround the limitation...
Wasn't someone working on a Associative Array static type that could be created at CTFE and run at runtime?
I'm guessing there isn't. Sadly still running into issues because of this :(
Jan 06 2022
next sibling parent reply bauss <jj_1337 live.dk> writes:
On Thursday, 6 January 2022 at 12:04:12 UTC, HuskyNator wrote:
 On Monday, 28 November 2016 at 14:41:44 UTC, Era Scarecrow 
 wrote:
 On Monday, 28 November 2016 at 09:06:34 UTC, Paolo Invernizzi 
 wrote:
 The point is that I was trying to avoid some cycle between 
 modules, detected by 2.072. This bug leads to pollution in 
 the use of static this only to workaround the limitation...
Wasn't someone working on a Associative Array static type that could be created at CTFE and run at runtime?
I'm guessing there isn't. Sadly still running into issues because of this :(
While not the exact same, there's a small work around here that can help in some cases: ```d immutable long[string] aa; shared static this() { aa = [ "foo": 5, "bar": 10, "baz": 2000 ]; } ```
Jan 06 2022
parent reply HuskyNator <HuskyNator protonmail.ch> writes:
On Thursday, 6 January 2022 at 13:33:24 UTC, bauss wrote:
 While not the exact same, there's a small work around here that 
 can help in some cases:

 ```d
 immutable long[string] aa;
 shared static this() {
     aa = [
       "foo": 5,
       "bar": 10,
       "baz": 2000
     ];
 }
 ```
Thanks a lot! I've tried it with static this() earlier, but the shared part fixes it for me.
Jan 06 2022
parent bauss <jj_1337 live.dk> writes:
On Thursday, 6 January 2022 at 16:01:40 UTC, HuskyNator wrote:
 On Thursday, 6 January 2022 at 13:33:24 UTC, bauss wrote:
 While not the exact same, there's a small work around here 
 that can help in some cases:

 ```d
 immutable long[string] aa;
 shared static this() {
     aa = [
       "foo": 5,
       "bar": 10,
       "baz": 2000
     ];
 }
 ```
Thanks a lot! I've tried it with static this() earlier, but the shared part fixes it for me.
The reason why it needs to be shared is because it's only executed once, where as just static this is executed for each thread.
Jan 06 2022
prev sibling parent reply Stefan Koch <uplink.coder googlemail.com> writes:
On Thursday, 6 January 2022 at 12:04:12 UTC, HuskyNator wrote:
 On Monday, 28 November 2016 at 14:41:44 UTC, Era Scarecrow 
 wrote:
 On Monday, 28 November 2016 at 09:06:34 UTC, Paolo Invernizzi 
 wrote:
 The point is that I was trying to avoid some cycle between 
 modules, detected by 2.072. This bug leads to pollution in 
 the use of static this only to workaround the limitation...
Wasn't someone working on a Associative Array static type that could be created at CTFE and run at runtime?
I'm guessing there isn't. Sadly still running into issues because of this :(
Actually I did a DMD patch for that some time ago. It's here: https://github.com/dlang/dmd/pull/13087 If there is interest in this I might revive it.
Jan 06 2022
parent Tejas <notrealemail gmail.com> writes:
On Thursday, 6 January 2022 at 16:01:09 UTC, Stefan Koch wrote:
 On Thursday, 6 January 2022 at 12:04:12 UTC, HuskyNator wrote:
 On Monday, 28 November 2016 at 14:41:44 UTC, Era Scarecrow 
 wrote:
 On Monday, 28 November 2016 at 09:06:34 UTC, Paolo Invernizzi 
 wrote:
 The point is that I was trying to avoid some cycle between 
 modules, detected by 2.072. This bug leads to pollution in 
 the use of static this only to workaround the limitation...
Wasn't someone working on a Associative Array static type that could be created at CTFE and run at runtime?
I'm guessing there isn't. Sadly still running into issues because of this :(
Actually I did a DMD patch for that some time ago. It's here: https://github.com/dlang/dmd/pull/13087 If there is interest in this I might revive it.
I feel like this should be done, if only for the sake of consistency We can add an idiom about how initializing large AAs can lead to binary bloat, so use the `shared static this(){}` workaround instead Would you please revise it? I'll take your side on this.
Jan 06 2022