Thread overview
Enum AA with classes not allowed anymore?
Oct 08, 2017
bauss
Oct 08, 2017
Daniel Kozak
Oct 11, 2017
bauss
Oct 11, 2017
Daniel Kozak
Oct 11, 2017
Daniel Kozak
Oct 11, 2017
Jonathan M Davis
Oct 13, 2017
bauss
October 08, 2017
I'm aware that the following has always been illegal:

enum a = new Foo();

However the following were used to work in older versions of DMD:

enum aa = [0 : new Foo("0"), 1 : new Foo("1")];

When did that change happen and what was the reason for the change? I were depending on AA's created like that to use them at compile-time.

It happens to break my following project:
https://github.com/bausshf/Diamond

More specifically:
https://github.com/bausshf/Diamond/blob/master/src/templates/parser.d#L13

The change has happened somewhere between 2.072.2 and the current version.
October 08, 2017
Up to      2.062  : Failure with output:
-----
onlineapp.d(10): Error: cannot evaluate new Foo("0") at compile time
onlineapp.d(10): Error: cannot evaluate new Foo("1") at compile time
-----

2.063   to 2.072.2: Success with output: Hello D
Since      2.073.2: Failure with output: onlineapp.d(10): Error: variable
onlineapp.aa : Unable to initialize enum with class or pointer to struct.
Use static const variable instead.

https://run.dlang.io/is/mJqayC

On Sun, Oct 8, 2017 at 4:29 AM, bauss via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> I'm aware that the following has always been illegal:
>
> enum a = new Foo();
>
> However the following were used to work in older versions of DMD:
>
> enum aa = [0 : new Foo("0"), 1 : new Foo("1")];
>
> When did that change happen and what was the reason for the change? I were depending on AA's created like that to use them at compile-time.
>
> It happens to break my following project: https://github.com/bausshf/Diamond
>
> More specifically: https://github.com/bausshf/Diamond/blob/master/src/templates/parser.d#L13
>
> The change has happened somewhere between 2.072.2 and the current version.
>


October 11, 2017
On Sunday, 8 October 2017 at 04:40:59 UTC, Daniel Kozak wrote:
> Up to      2.062  : Failure with output:
> -----
> onlineapp.d(10): Error: cannot evaluate new Foo("0") at compile time
> onlineapp.d(10): Error: cannot evaluate new Foo("1") at compile time
> -----
>
> 2.063   to 2.072.2: Success with output: Hello D
> Since      2.073.2: Failure with output: onlineapp.d(10): Error: variable
> onlineapp.aa : Unable to initialize enum with class or pointer to struct.
> Use static const variable instead.
>
> https://run.dlang.io/is/mJqayC
>
> On Sun, Oct 8, 2017 at 4:29 AM, bauss via Digitalmars-d < digitalmars-d@puremagic.com> wrote:
>
>> [...]

Do you know what the reason for the change is and are there any workarounds to actually declare AA's with classes that can be used at compile-time then?
October 11, 2017
Not sure, but I belive this could be one of reasons: https://issues.dlang.org/show_bug.cgi?id=15989

On Wed, Oct 11, 2017 at 4:54 PM, bauss via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> On Sunday, 8 October 2017 at 04:40:59 UTC, Daniel Kozak wrote:
>
>> Up to      2.062  : Failure with output:
>> -----
>> onlineapp.d(10): Error: cannot evaluate new Foo("0") at compile time
>> onlineapp.d(10): Error: cannot evaluate new Foo("1") at compile time
>> -----
>>
>> 2.063   to 2.072.2: Success with output: Hello D
>> Since      2.073.2: Failure with output: onlineapp.d(10): Error: variable
>> onlineapp.aa : Unable to initialize enum with class or pointer to struct.
>> Use static const variable instead.
>>
>> https://run.dlang.io/is/mJqayC
>>
>> On Sun, Oct 8, 2017 at 4:29 AM, bauss via Digitalmars-d < digitalmars-d@puremagic.com> wrote:
>>
>> [...]
>>>
>>
> Do you know what the reason for the change is and are there any workarounds to actually declare AA's with classes that can be used at compile-time then?
>


October 11, 2017
so you can try to use static immutable insted of enum

On Wed, Oct 11, 2017 at 5:04 PM, Daniel Kozak <kozzi11@gmail.com> wrote:

> Not sure, but I belive this could be one of reasons: https://issues.dlang.org/show_bug.cgi?id=15989
>
> On Wed, Oct 11, 2017 at 4:54 PM, bauss via Digitalmars-d < digitalmars-d@puremagic.com> wrote:
>
>> On Sunday, 8 October 2017 at 04:40:59 UTC, Daniel Kozak wrote:
>>
>>> Up to      2.062  : Failure with output:
>>> -----
>>> onlineapp.d(10): Error: cannot evaluate new Foo("0") at compile time
>>> onlineapp.d(10): Error: cannot evaluate new Foo("1") at compile time
>>> -----
>>>
>>> 2.063   to 2.072.2: Success with output: Hello D
>>> Since      2.073.2: Failure with output: onlineapp.d(10): Error: variable
>>> onlineapp.aa : Unable to initialize enum with class or pointer to struct.
>>> Use static const variable instead.
>>>
>>> https://run.dlang.io/is/mJqayC
>>>
>>> On Sun, Oct 8, 2017 at 4:29 AM, bauss via Digitalmars-d < digitalmars-d@puremagic.com> wrote:
>>>
>>> [...]
>>>>
>>>
>> Do you know what the reason for the change is and are there any workarounds to actually declare AA's with classes that can be used at compile-time then?
>>
>
>


October 11, 2017
On Wednesday, October 11, 2017 17:05:19 Daniel Kozak via Digitalmars-d wrote:
> so you can try to use static immutable insted of enum

Yeah. Similarly, you could just have a regular function that you call at compile time that returns what you want (assuming that it's not being assigned to an enum) - then if it's just being used to generate something that you actually want to keep around after compiling, you're not stuck with the AA continuing to exist past compile time.

I don't know that it will ever happen, but there has been talk of disallowing enums of anything that will allocate, because you pretty much never want that (since it will allocate every time it's used), and it's easy to do accidentally.

- Jonathan M Davis

October 13, 2017
On Wednesday, 11 October 2017 at 17:40:15 UTC, Jonathan M Davis wrote:
> On Wednesday, October 11, 2017 17:05:19 Daniel Kozak via Digitalmars-d wrote:
>> so you can try to use static immutable insted of enum
>
> Yeah. Similarly, you could just have a regular function that you call at compile time that returns what you want (assuming that it's not being assigned to an enum) - then if it's just being used to generate something that you actually want to keep around after compiling, you're not stuck with the AA continuing to exist past compile time.
>
> I don't know that it will ever happen, but there has been talk of disallowing enums of anything that will allocate, because you pretty much never want that (since it will allocate every time it's used), and it's easy to do accidentally.
>
> - Jonathan M Davis

Yeah I ended up making property functions that returns the AA's with what I want.

Ex.

@property string[string] myAA() {
    string[string] aa;

    // ... populate aa

    return aa;
}

Because then I didn't have to change any places it was used. Since it's compile-time it shouldn't matter too much that it might be called multiple times and generate a new AA. There seem to be no better way to cache it other than local variables where it's used.

I did have one enum AA I could change to a static AA since it wasn't called during compile-time, so I guess there were some advantages by not being able to compile with latest version; like I wouldn't have caught that mistake if I didn't come by this.