On 11 November 2013 21:38, Daniel Murphy <yebblies@nospamgmail.com> wrote:

> "Manu" <turkeyman@gmail.com> wrote in message news:mailman.355.1384158631.9546.digitalmars-d@puremagic.com...
> > immutable string[string] priorityMap = [
> > "1" : "blocker",
> > "2" : "critical",
> > "3" : "critical",
> > "4" : "major",
> > "5" : "major",
> > "6" : "major",
> > "7" : "minor",
> > "8" : "minor",
> > "9" : "trivial" ];
> >
> > main.d(56): Error: non-constant expression ["1":"blocker",
> "2":"critical",
> > "3":"critical", "4":"major", "5":"major", "6":"major", "7":"minor", "8":"minor", "9":"trivial"]
> >
> > This is tedious, how long has it been now?
> > Seriously, static map's are super-important, they should be able to be
> > made
> > immutable, and also be able to be initialised.
> >
> > Maybe this could be factored into the improvements for 2.065?
> >
>
> I think yes, it can be done for 2.065.  Someone remind me if we get close and it isn't done yet.
>

I've just run into this again today. It's still very annoying. Consider this a reminder? :)

On 12 November 2013 18:09, Don <x@nospam.com> wrote:

> On Monday, 11 November 2013 at 11:39:06 UTC, Daniel Murphy wrote:
>
>> "Manu" <turkeyman@gmail.com> wrote in message news:mailman.355.1384158631.9546.digitalmars-d@puremagic.com...
>>
>>> immutable string[string] priorityMap = [
>>> "1" : "blocker",
>>> "2" : "critical",
>>> "3" : "critical",
>>> "4" : "major",
>>> "5" : "major",
>>> "6" : "major",
>>> "7" : "minor",
>>> "8" : "minor",
>>> "9" : "trivial" ];
>>>
>>> main.d(56): Error: non-constant expression ["1":"blocker",
>>> "2":"critical",
>>> "3":"critical", "4":"major", "5":"major", "6":"major", "7":"minor",
>>> "8":"minor", "9":"trivial"]
>>>
>>> This is tedious, how long has it been now?
>>> Seriously, static map's are super-important, they should be able to be
>>> made
>>> immutable, and also be able to be initialised.
>>>
>>> Maybe this could be factored into the improvements for 2.065?
>>>
>>>
>> I think yes, it can be done for 2.065.  Someone remind me if we get close and it isn't done yet.
>>
>
>
> IIRC the poor performance of array literals and AA literals is because they're not always literals, sometimes they are variables (!) and the compiler assumes the worst case. You are allowed to write:
>
> void foo(int some_param)
> {
>     immutable string[int] = [ 1: "abc", some_param: "def"];
> }
>
> I wish we could get rid of that silliness entirely.
>
>
> If the members are compile-time expressions, you probably want to mark the variable as static const/static immutable.
>

I've also had this thought. Logically, you shouldn't need to declare an immutable thing static (although currently, you do), although the advantage would be a guaranteed compile error if you try to do something silly like initialise from a variable.

On Sat, 11 Jan 2014 22:08:25 -0600, Manu <turkeyman@gmail.com> wrote:

> On 12 November 2013 18:09, Don <x@nospam.com> wrote:
>>
>> On Monday, 11 November 2013 at 11:39:06 UTC, Daniel Murphy wrote:
>>
>>>
>>> "Manu" <turkeyman@gmail.com> wrote in message
>>>
>>> news:mailman.355.1384158631.9546.digitalmars-d@puremagic.com...
>>>
>>>>
>>>> immutable string[string] priorityMap = [
>>>>
>>>> "1" : "blocker",
>>>>
>>>> "2" : "critical",
>>>>
>>>> "3" : "critical",
>>>>
>>>> "4" : "major",
>>>>
>>>> "5" : "major",
>>>>
>>>> "6" : "major",
>>>>
>>>> "7" : "minor",
>>>>
>>>> "8" : "minor",
>>>>
>>>> "9" : "trivial" ];
>>>>
>>>>
>>>>
>>>> main.d(56): Error: non-constant expression ["1":"blocker", "2":"critical",
>>>>
>>>> "3":"critical", "4":"major", "5":"major", "6":"major", "7":"minor",
>>>>
>>>> "8":"minor", "9":"trivial"]
>>>>
>>>>
>>>>
>>>> This is tedious, how long has it been now?
>>>>
>>>> Seriously, static map's are super-important, they should be able to be made
>>>>
>>>> immutable, and also be able to be initialised.
>>>>
>>>>
>>>>
>>>> Maybe this could be factored into the improvements for 2.065?
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>> I think yes, it can be done for 2.065.  Someone remind me if we get close
>>>
>>> and it isn't done yet.
>>>
>>
>>
>>
>>
>>
>> IIRC the poor performance of array literals and AA literals is because they're not always >>literals, sometimes they are variables (!) and the compiler assumes the worst case. You are >>allowed to write:
>>
>>
>>
>> void foo(int some_param)
>>
>> {
>>
>>    immutable string[int] = [ 1: "abc", some_param: "def"];
>>
>> }
>>
>>
>>
>> I wish we could get rid of that silliness entirely.
>>
>>
>>
>>
>>
>> If the members are compile-time expressions, you probably want to mark the variable as static >>const/static immutable.
>>
>
> I've also had this thought. Logically, you shouldn't need to declare an immutable thing static >(although currently, you do), although the advantage would be a guaranteed compile error if you try >to do something silly like initialise from a variable.

I would disagree with that statement, because it is my understanding of immutable that it merely means that the value is not modified after it is initialized, it does not however mean that the value is determinate at compile-time, nor that it is even the same in all invocations of a function.

On 12 January 2014 14:29, Orvid King <blah38621@gmail.com> wrote:

> On Sat, 11 Jan 2014 22:08:25 -0600, Manu <turkeyman@gmail.com> wrote:
>
>  On 12 November 2013 18:09, Don <x@nospam.com> wrote:
>>
>>>
>>> On Monday, 11 November 2013 at 11:39:06 UTC, Daniel Murphy wrote:
>>>
>>>
>>>> "Manu" <turkeyman@gmail.com> wrote in message
>>>>
>>>> news:mailman.355.1384158631.9546.digitalmars-d@puremagic.com...
>>>>
>>>>
>>>>> immutable string[string] priorityMap = [
>>>>>
>>>>> "1" : "blocker",
>>>>>
>>>>> "2" : "critical",
>>>>>
>>>>> "3" : "critical",
>>>>>
>>>>> "4" : "major",
>>>>>
>>>>> "5" : "major",
>>>>>
>>>>> "6" : "major",
>>>>>
>>>>> "7" : "minor",
>>>>>
>>>>> "8" : "minor",
>>>>>
>>>>> "9" : "trivial" ];
>>>>>
>>>>>
>>>>>
>>>>> main.d(56): Error: non-constant expression ["1":"blocker",
>>>>> "2":"critical",
>>>>>
>>>>> "3":"critical", "4":"major", "5":"major", "6":"major", "7":"minor",
>>>>>
>>>>> "8":"minor", "9":"trivial"]
>>>>>
>>>>>
>>>>>
>>>>> This is tedious, how long has it been now?
>>>>>
>>>>> Seriously, static map's are super-important, they should be able to be made
>>>>>
>>>>> immutable, and also be able to be initialised.
>>>>>
>>>>>
>>>>>
>>>>> Maybe this could be factored into the improvements for 2.065?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> I think yes, it can be done for 2.065.  Someone remind me if we get close
>>>>
>>>> and it isn't done yet.
>>>>
>>>>
>>>
>>>
>>>
>>>
>>> IIRC the poor performance of array literals and AA literals is because they're not always >>literals, sometimes they are variables (!) and the compiler assumes the worst case. You are >>allowed to write:
>>>
>>>
>>>
>>> void foo(int some_param)
>>>
>>> {
>>>
>>>    immutable string[int] = [ 1: "abc", some_param: "def"];
>>>
>>> }
>>>
>>>
>>>
>>> I wish we could get rid of that silliness entirely.
>>>
>>>
>>>
>>>
>>>
>>> If the members are compile-time expressions, you probably want to mark the variable as static >>const/static immutable.
>>>
>>>
>> I've also had this thought. Logically, you shouldn't need to declare an immutable thing static >(although currently, you do), although the advantage would be a guaranteed compile error if you try >to do something silly like initialise from a variable.
>>
>
> I would disagree with that statement, because it is my understanding of immutable that it merely means that the value is not modified after it is initialized, it does not however mean that the value is determinate at compile-time, nor that it is even the same in all invocations of a function.
>

If an immutable is initialised to a literal value, then there is no possible way for variation to exist. It certainly is the same in all invocations of the function, and there's no need to re-allocate+initialise it on every call to the function.

On Sunday, 12 January 2014 at 04:05:02 UTC, Manu wrote:
> I've just run into this again today. It's still very annoying.
> Consider this a reminder? :)

Do you even understand the problem? This is an extremely complicated thing that you are asking, you can't do anything like it in any other programming language that I'm aware of. We have been making progress in making it work over the years, but for AAs it's at an impasse due to how AAs are implemented in the compiler.

This kind of nagging is not helping anyone, it's just annoying.

On 12 January 2014 15:05, Jakob Ovrum <jakobovrum@gmail.com> wrote:

> On Sunday, 12 January 2014 at 04:05:02 UTC, Manu wrote:
>
>> I've just run into this again today. It's still very annoying. Consider this a reminder? :)
>>
>
> Do you even understand the problem? This is an extremely complicated thing that you are asking, you can't do anything like it in any other programming language that I'm aware of. We have been making progress in making it work over the years, but for AAs it's at an impasse due to how AAs are implemented in the compiler.
>
> This kind of nagging is not helping anyone, it's just annoying.
>

No I don't understand the problem. What I do know is that Daniel said to
remind him, so I did.
He made it sound like it was quite fixable-able in November.

"Manu" <turkeyman@gmail.com> wrote in message news:mailman.334.1389499497.15871.digitalmars-d@puremagic.com...
> I've just run into this again today. It's still very annoying.
> Consider this a reminder? :)

AAs should be rolled back first, and these have been sitting there for a couple of months.

https://github.com/D-Programming-Language/dmd/pull/2856
https://github.com/D-Programming-Language/druntime/pull/668

Walter has decided that this coming release will only be bugfixes... kind of a useless thing to do for an open source project, as him refusing to review/merge my enhancement pulls doesn’t inspire me to work on ‘actual bugs’.

"Jakob Ovrum"  wrote in message news:izbxftjgrkgfehqehznn@forum.dlang.org...
> Do you even understand the problem? This is an extremely complicated thing that you are asking, you can't do anything like it in any other programming language that I'm aware of. We have been making progress in making it work over the years, but for AAs it's at an impasse due to how AAs are implemented in the compiler.

It's not _that_ bad.  There are open pull requests to convert AAs to use UFCS instead of the current broken hacks, and crossing from compile to run-time just means matching the layout of the runtime AAs in AssocArrayExpression::toDt.

> This kind of nagging is not helping anyone, it's just annoying.

I asked him to.  You could at least read the quoted text. 

On Sunday, 12 January 2014 at 05:22:22 UTC, Manu wrote:
> No I don't understand the problem. What I do know is that Daniel said to
> remind him, so I did.

I'm sorry, that was entirely my mistake.

On Sunday, 12 January 2014 at 11:32:00 UTC, Daniel Murphy wrote:
> It's not _that_ bad.  There are open pull requests to convert AAs to use UFCS instead of the current broken hacks, and crossing from compile to run-time just means matching the layout of the runtime AAs in AssocArrayExpression::toDt.

Alright, that looks more short-term viable than Stepanov's approach. I don't think I'm overplaying the issue though - it is a tall order to ask for compile-time construction of AAs that are then usable at runtime, and it's not fair to present them as a fundamental feature, or their absence as a bug, because it's not like other languages have anything near this kind of power.

It props up quite often but it's usually due to a (perfectly understandable) misunderstanding of D's initializers for fields and module-level/static variables. The expectation is that it works like in Java and C#, where these initializers are run before main or on construction of the type. Fortunately, when the D approach is explained, thus explaining why the code errors[1], most people tend to be either content or excited.

[1] The error message was fine for D1, but the phrasing is problematic for D2...