November 09, 2011
Is it possible to modify DMD to allow a program like:


immutable int[int] aa = [1:15, 2: 7];
void main() {}


With the latest DMD it gives:
test.d(1): Error: non-constant expression [1:15,2:7]

Global immutable associative arrays are handy in script-like programs, I use them now and then in Python (despite they are not immutable).
This is a workaround for script-like programs, that I sometimes use:


immutable int[int] aa;
static this() {
    aa = [1:15, 2: 7];
}
void main() {}


But when possible I try to avoid using static this.

Bye,
bearophile
November 09, 2011
I think this is a bug and i even recall seeing it in bugzilla, but i don't have a link to it.

On Wed, Nov 9, 2011 at 10:43 AM, bearophile <bearophileHUGS@lycos.com> wrote:
> Is it possible to modify DMD to allow a program like:
>
>
> immutable int[int] aa = [1:15, 2: 7];
> void main() {}
>
>
> With the latest DMD it gives:
> test.d(1): Error: non-constant expression [1:15,2:7]
>
> Global immutable associative arrays are handy in script-like programs, I use them now and then in Python (despite they are not immutable).
> This is a workaround for script-like programs, that I sometimes use:
>
>
> immutable int[int] aa;
> static this() {
>    aa = [1:15, 2: 7];
> }
> void main() {}
>
>
> But when possible I try to avoid using static this.
>
> Bye,
> bearophile
>
January 24, 2013
Googling is so good for necro thread resurrection.

What is idiomatic way in D to initialize static immutable AA to be accessible in CTFE at the same? static this() won't help here, unfortunately.

On Wednesday, 9 November 2011 at 10:44:08 UTC, Gor Gyolchanyan wrote:
> I think this is a bug and i even recall seeing it in bugzilla, but i
> don't have a link to it.
>
> On Wed, Nov 9, 2011 at 10:43 AM, bearophile <bearophileHUGS@lycos.com> wrote:
>> Is it possible to modify DMD to allow a program like:
>>
>>
>> immutable int[int] aa = [1:15, 2: 7];
>> void main() {}
>>
>>
>> With the latest DMD it gives:
>> test.d(1): Error: non-constant expression [1:15,2:7]
>>
>> Global immutable associative arrays are handy in script-like programs, I use them now and then in Python (despite they are not immutable).
>> This is a workaround for script-like programs, that I sometimes use:
>>
>>
>> immutable int[int] aa;
>> static this() {
>>    aa = [1:15, 2: 7];
>> }
>> void main() {}
>>
>>
>> But when possible I try to avoid using static this.
>>
>> Bye,
>> bearophile

January 24, 2013
You know what? Screw idiomatic. Is there _any_ way to use a compile-time associative array literal?
January 24, 2013
On 01/24/13 19:36, mist wrote:
> You know what? Screw idiomatic. Is there _any_ way to use a compile-time associative array literal?

   template ctAA(alias aal) { enum ctAA = aal; }

   enum aa = ctAA!(["one":1, "two":2]);

   int main() {
      enum x = aa["two"];
      pragma(msg, x.stringof);
      return x;
   }

artur
January 24, 2013
Thank you. So simple and so illogical. Looking at your example I have zero understanding why AA literals just do not work at compile-time just out of the box.

On Thursday, 24 January 2013 at 19:30:27 UTC, Artur Skawina wrote:
> On 01/24/13 19:36, mist wrote:
>> You know what? Screw idiomatic. Is there _any_ way to use a compile-time associative array literal?
>
>    template ctAA(alias aal) { enum ctAA = aal; }
>
>    enum aa = ctAA!(["one":1, "two":2]);
>
>    int main() {
>       enum x = aa["two"];
>       pragma(msg, x.stringof);
>       return x;
>    }
>
> artur

January 24, 2013
On Thu, Jan 24, 2013 at 09:00:55PM +0100, mist wrote:
> Thank you. So simple and so illogical. Looking at your example I have zero understanding why AA literals just do not work at compile-time just out of the box.
[...]

Because the current AA implementation sucks. You're welcome to try to improve it. I've tried before, but it's non-trivial because it's schizophrenically split across two places in druntime and sprinkled all over the compiler. Good luck. Should you succeed, you will have done a MAJOR favor to the entire D community (Andrei, for one, will be eternally grateful).


T

-- 
"A man's wife has more power over him than the state has." -- Ralph Emerson
January 24, 2013
Ah, I get the trick - enum does not really hold an AA, it is just a copy-paste entity. Change the aa from enum to immutable - and it won't compile.
January 24, 2013
Sorry, no offense meant from my side :) I have followed your attempts on github and do not really feel in shape and competence to try to add anything there now. I simply could not understand why assignment to enum works and to immutable - not. Then remembered they enums are simply replaced with literals again and again every time when used and got it.

On Thursday, 24 January 2013 at 20:10:21 UTC, H. S. Teoh wrote:
> Because the current AA implementation sucks. You're welcome to try to
> improve it. I've tried before, but it's non-trivial because it's
> schizophrenically split across two places in druntime and sprinkled all
> over the compiler. Good luck. Should you succeed, you will have done a
> MAJOR favor to the entire D community (Andrei, for one, will be
> eternally grateful).
>
>
> T

January 24, 2013
On Thu, Jan 24, 2013 at 09:15:02PM +0100, mist wrote:
> Sorry, no offense meant from my side :) I have followed your attempts on github and do not really feel in shape and competence to try to add anything there now. I simply could not understand why assignment to enum works and to immutable - not. Then remembered they enums are simply replaced with literals again and again every time when used and got it.

I didn't take any offense. Just stating that AA's as currently implemented leaves a lot to be desired, and it's not going to improve unless *somebody* takes up the challenge to fix it.


> On Thursday, 24 January 2013 at 20:10:21 UTC, H. S. Teoh wrote:
> >Because the current AA implementation sucks. You're welcome to try to improve it. I've tried before, but it's non-trivial because it's schizophrenically split across two places in druntime and sprinkled all over the compiler. Good luck. Should you succeed, you will have done a MAJOR favor to the entire D community (Andrei, for one, will be eternally grateful).
[...]


T

-- 
Elegant or ugly code as well as fine or rude sentences have something in common: they don't depend on the language. -- Luca De Vitis
« First   ‹ Prev
1 2
Top | Discussion index | About this forum | D home