best/proper way to declare constants ?

[someone]

On Thursday, 5 August 2021 at 16:24:21 UTC, jfondren wrote:
> On Thursday, 5 August 2021 at 16:06:58 UTC, someone wrote:
>> So if we are talking AA-arrays at compile-time only there 
>> should be nothing wrong with the following code ... right ?
> ...
>> private enum pudtLocations = [
>>    r"BUE"d : structureLocation(r"arg"d, r"Buenos Aires"d, 
>> r"ART"d),
>>    r"GRU"d : structureLocation(r"bra"d, r"São Paulo"d, 
>> r"BRT"d),
>>    r"HHN"d : structureLocation(r"deu"d, r"Frankfurt am Main"d, 
>> r"CET"d),
>>    r"LHR"d : structureLocation(r"gbr"d, r"London"d, r"UTC"d),
>>    r"NYC"d : structureLocation(r"usa"d, r"New York"d, r"EST"d)
>>    ];
>
> Every time you use this variable in your program, it's as if 
> you retyped this definition, which can mean runtime work 
> building the hash table where you use it, which can mean very 
> surprising performance hits. Consider:
>
> ```d
> enum aa = [1: 0];
>
> // this is fine
> unittest {
>     foreach (key; aa.byKey)
>         assert(aa[key] == 0);
> }
>
> // Error: associative array literal in `@nogc` function 
> `enumaa.__unittest_L9_C7` may cause a GC allocation
> @nogc unittest {
>     foreach (key; aa.byKey)
>         assert(aa[key] == 0);
> }
> ```
>
> It's not iteration that causes allocation, but the runtime 
> building of the AA that has to happen on the spot for it to be 
> iterated.
>
> Maybe this isn't getting discussed directly enough. As rules:
>
> 1. don't use enum for AA literals
>
> 2. module-scoped AAs can be initialized in module constructors, 
> like `shared static this`
>
> 3. (depending very precisely on what you want to do, you can 
> break #1 with no runtime cost. For example if you never need to 
> iterate over the AA or look up a compiletime-unknown key, if 
> all your uses are `aa["literal key"]`, then the AA won't need 
> to be constructed at runtime and this is just like putting the 
> value of that key at the site)
>
> ```d
> enum aa = [1: 0];
>
> // this is fine
> unittest {
>     assert(aa[1] == 0);
> }
>
> // this is still fine
> @nogc unittest {
>     assert(aa[1] == 0);
> }
> ```
>
> (but that't not likely to apply to your case, especially since 
> you mentioned wanting to get this data from a file at program 
> start and not need literals in your program.)

Yes. Of course I remember the post you mention in which I stated 
the possibility of loading data from a file. And somehow this 
post in which I am asking for advice to finally nail-down const 
usage in D went back to the problem I encountered with AA at 
compile-time (byKeyValue) when I did not clearly understand the 
differences of using arrays/AA at compile-time vs run-time.

My conclusion of said post was that I have to find an alternative 
to AA at compile-time, and then, in this post, when I saw the 
comment:

"AA's are already available at compile-time" [H S Teoth]

and then the related:

"We really need to fix this" [H S Teoth]

I thought that probably there was nothing wrong with my code to 
begin with and thus I somehow re-asked the original question 
about AA at compile-time.

As you pointed me, using them the way I am using them, leads to 
usable code at the cost of horrible-performance compilation 
because of the copy/paste/build-hash-table-once-again the 
compiler has to do *each* time I reference them.

I already assumed that loading the data from file is a goner.

So this leaves me with two choices:

- keep the code as it is incurring higher-than expected 
compilation-time: this is solely used in a module to build 
classes, I guess pretty minimal usage, but I don't know where 
this app will eventually go so better get it right to begin with

- find a better alternative

Thanks for your advice jfondren :) !