www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - AA literals/initialisation

reply Manu <turkeyman gmail.com> writes:
--089e0149ce5c8d623904eae236f3
Content-Type: text/plain; charset=UTF-8

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?

--089e0149ce5c8d623904eae236f3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>immutable string[string] priorityMap =3D [</div><div>=
<span class=3D"" style=3D"white-space:pre">		</span>&quot;1&quot; : &quot;b=
locker&quot;,</div><div><span class=3D"" style=3D"white-space:pre">		</span=
&quot;2&quot; : &quot;critical&quot;,</div>

uot;critical&quot;,</div><div><span class=3D"" style=3D"white-space:pre"> = </span>&quot;4&quot; : &quot;major&quot;,</div><div><span class=3D"" style= =3D"white-space:pre"> </span>&quot;5&quot; : &quot;major&quot;,</div> <div><span class=3D"" style=3D"white-space:pre"> </span>&quot;6&quot; : &q= uot;major&quot;,</div><div><span class=3D"" style=3D"white-space:pre"> </s= pan>&quot;7&quot; : &quot;minor&quot;,</div><div><span class=3D"" style=3D"= white-space:pre"> </span>&quot;8&quot; : &quot;minor&quot;,</div> <div><span class=3D"" style=3D"white-space:pre"> </span>&quot;9&quot; : &q= uot;trivial&quot; ];</div><div><br></div>main.d(56): Error: non-constant ex= pression [&quot;1&quot;:&quot;blocker&quot;, &quot;2&quot;:&quot;critical&q= uot;, &quot;3&quot;:&quot;critical&quot;, &quot;4&quot;:&quot;major&quot;, = &quot;5&quot;:&quot;major&quot;, &quot;6&quot;:&quot;major&quot;, &quot;7&q= uot;:&quot;minor&quot;, &quot;8&quot;:&quot;minor&quot;, &quot;9&quot;:&quo= t;trivial&quot;]<br> <div><br></div><div>This is tedious, how long has it been now?</div><div>Se= riously, static map&#39;s are super-important, they should be able to be ma= de immutable, and also be able to be initialised.</div><div><br></div><div> Maybe this could be factored into the improvements for 2.065?</div></div> --089e0149ce5c8d623904eae236f3--
Nov 11 2013
next sibling parent "simendsjo" <simendsjo gmail.com> writes:
On Monday, 11 November 2013 at 08:30:32 UTC, Manu wrote:
 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?

The workaround is simple at global scope, but I agree it clutters the code: immutable string[string] priorityMap; shared static this() { priorityMap = [ "1" : "blocker", "2" : "critical", "3" : "critical", "4" : "major", "5" : "major", "6" : "major", "7" : "minor", "8" : "minor", "9" : "trivial" ]; }
Nov 11 2013
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--001a11c339e69f896304eae38b7f
Content-Type: text/plain; charset=UTF-8

A work-around of that type required by a core language feature is not a
sign of quality...

It get's me every single time, and I forget and have to go and find out why
again each time.
Please, fix it finally.


On 11 November 2013 18:33, simendsjo <simendsjo gmail.com> wrote:

 On Monday, 11 November 2013 at 08:30:32 UTC, Manu wrote:

 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?

The workaround is simple at global scope, but I agree it clutters the code: immutable string[string] priorityMap; shared static this() { priorityMap = [ "1" : "blocker", "2" : "critical", "3" : "critical", "4" : "major", "5" : "major", "6" : "major", "7" : "minor", "8" : "minor", "9" : "trivial" ]; }

--001a11c339e69f896304eae38b7f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">A work-around of that type required by a core language fea= ture is not a sign of quality...<div><br></div><div>It get&#39;s me every s= ingle time, and I forget and have to go and find out why again each time.<b= r> </div><div><div>Please, fix it finally.</div></div></div><div class=3D"gmai= l_extra"><br><br><div class=3D"gmail_quote">On 11 November 2013 18:33, sime= ndsjo <span dir=3D"ltr">&lt;<a href=3D"mailto:simendsjo gmail.com" target= =3D"_blank">simendsjo gmail.com</a>&gt;</span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><div class=3D"HOEnZb"><div class=3D"h5">On M= onday, 11 November 2013 at 08:30:32 UTC, Manu wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> immutable string[string] priorityMap =3D [<br> &quot;1&quot; : &quot;blocker&quot;,<br> &quot;2&quot; : &quot;critical&quot;,<br> &quot;3&quot; : &quot;critical&quot;,<br> &quot;4&quot; : &quot;major&quot;,<br> &quot;5&quot; : &quot;major&quot;,<br> &quot;6&quot; : &quot;major&quot;,<br> &quot;7&quot; : &quot;minor&quot;,<br> &quot;8&quot; : &quot;minor&quot;,<br> &quot;9&quot; : &quot;trivial&quot; ];<br> <br> main.d(56): Error: non-constant expression [&quot;1&quot;:&quot;blocker&quo= t;, &quot;2&quot;:&quot;critical&quot;,<br> &quot;3&quot;:&quot;critical&quot;, &quot;4&quot;:&quot;major&quot;, &quot;= 5&quot;:&quot;major&quot;, &quot;6&quot;:&quot;major&quot;, &quot;7&quot;:&= quot;minor&quot;,<br> &quot;8&quot;:&quot;minor&quot;, &quot;9&quot;:&quot;trivial&quot;]<br> <br> This is tedious, how long has it been now?<br> Seriously, static map&#39;s are super-important, they should be able to be = made<br> immutable, and also be able to be initialised.<br> <br> Maybe this could be factored into the improvements for 2.065?<br> </blockquote> <br></div></div> The workaround is simple at global scope, but I agree it clutters the code:= <br> <br> =C2=A0 immutable string[string] priorityMap;<br> =C2=A0 shared static this() {<div class=3D"HOEnZb"><div class=3D"h5"><br> =C2=A0 =C2=A0 =C2=A0 priorityMap =3D [<br> =C2=A0 =C2=A0 =C2=A0 &quot;1&quot; : &quot;blocker&quot;,<br> =C2=A0 =C2=A0 =C2=A0 &quot;2&quot; : &quot;critical&quot;,<br> =C2=A0 =C2=A0 =C2=A0 &quot;3&quot; : &quot;critical&quot;,<br> =C2=A0 =C2=A0 =C2=A0 &quot;4&quot; : &quot;major&quot;,<br> =C2=A0 =C2=A0 =C2=A0 &quot;5&quot; : &quot;major&quot;,<br> =C2=A0 =C2=A0 =C2=A0 &quot;6&quot; : &quot;major&quot;,<br> =C2=A0 =C2=A0 =C2=A0 &quot;7&quot; : &quot;minor&quot;,<br> =C2=A0 =C2=A0 =C2=A0 &quot;8&quot; : &quot;minor&quot;,<br> =C2=A0 =C2=A0 =C2=A0 &quot;9&quot; : &quot;trivial&quot; ];<br> =C2=A0 }<br> </div></div></blockquote></div><br></div> --001a11c339e69f896304eae38b7f--
Nov 11 2013
prev sibling next sibling parent "Daniel Kozak" <kozzi11 gmail.com> writes:
On Monday, 11 November 2013 at 08:30:32 UTC, Manu wrote:
 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?

this work ok for me: immutable priorityMap = [ "1" : "blocker", "2" : "critical", "3" : "critical", "4" : "major", "5" : "major", "6" : "major", "7" : "minor", "8" : "minor", "9" : "trivial" ];
Nov 11 2013
prev sibling next sibling parent reply "Daniel Kozak" <kozzi11 gmail.com> writes:
On Monday, 11 November 2013 at 08:30:32 UTC, Manu wrote:
 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?

And even this works ok: immutable string[string] priorityMap = [ "1" : "blocker", "2" : "critical", "3" : "critical", "4" : "major", "5" : "major", "6" : "major", "7" : "minor", "8" : "minor", "9" : "trivial" ];
Nov 11 2013
parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
11-Nov-2013 15:06, Manu пишет:

     but enum works fine:

     enum priorityMap = [

          "1" : "blocker",
          "2" : "critical",
          "3" : "critical",
          "4" : "major",
          "5" : "major",
          "6" : "major",
          "7" : "minor",
          "8" : "minor",
          "9" : "trivial" ];


 So it does... I didn't think of an enum AA ;)

... copy pastes that literal everywhere, I'm sure you'll like it ;) -- Dmitry Olshansky
Nov 11 2013
parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
11-Nov-2013 15:55, simendsjo пишет:
 On Monday, 11 November 2013 at 11:43:01 UTC, Dmitry Olshansky
 wrote:
 11-Nov-2013 15:06, Manu пишет:

    but enum works fine:

    enum priorityMap = [

         "1" : "blocker",
         "2" : "critical",
         "3" : "critical",
         "4" : "major",
         "5" : "major",
         "6" : "major",
         "7" : "minor",
         "8" : "minor",
         "9" : "trivial" ];


 So it does... I didn't think of an enum AA ;)

... copy pastes that literal everywhere, I'm sure you'll like it ;)

Will it be copied even if you just use it ("1" in priorityMap), or only if you pass it around as a parameter or assign it to variables?

It will do whatever it does when written as literal by hand. And it's nothing clever still, last time I checked - allocation, everywhere. -- Dmitry Olshansky
Nov 11 2013
prev sibling next sibling parent "Daniel Kozak" <kozzi11 gmail.com> writes:
On Monday, 11 November 2013 at 10:11:18 UTC, Daniel Kozak wrote:
 On Monday, 11 November 2013 at 08:30:32 UTC, Manu wrote:
 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?

And even this works ok: immutable string[string] priorityMap = [ "1" : "blocker", "2" : "critical", "3" : "critical", "4" : "major", "5" : "major", "6" : "major", "7" : "minor", "8" : "minor", "9" : "trivial" ];

Ohh, but non works on module scope, so yes, it would be fine to fix this
Nov 11 2013
prev sibling next sibling parent "Daniel Kozak" <kozzi11 gmail.com> writes:
On Monday, 11 November 2013 at 10:13:02 UTC, Daniel Kozak wrote:
 On Monday, 11 November 2013 at 10:11:18 UTC, Daniel Kozak wrote:
 On Monday, 11 November 2013 at 08:30:32 UTC, Manu wrote:
 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?

And even this works ok: immutable string[string] priorityMap = [ "1" : "blocker", "2" : "critical", "3" : "critical", "4" : "major", "5" : "major", "6" : "major", "7" : "minor", "8" : "minor", "9" : "trivial" ];

Ohh, but non works on module scope, so yes, it would be fine to fix this

but enum works fine: enum priorityMap = [ "1" : "blocker", "2" : "critical", "3" : "critical", "4" : "major", "5" : "major", "6" : "major", "7" : "minor", "8" : "minor", "9" : "trivial" ];
Nov 11 2013
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--047d7b41c0bafca60604eae4ba8e
Content-Type: text/plain; charset=UTF-8

On 11 November 2013 20:14, Daniel Kozak <kozzi11 gmail.com> wrote:

 On Monday, 11 November 2013 at 10:13:02 UTC, Daniel Kozak wrote:

 On Monday, 11 November 2013 at 10:11:18 UTC, Daniel Kozak wrote:

 On Monday, 11 November 2013 at 08:30:32 UTC, Manu wrote:

 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?

And even this works ok: immutable string[string] priorityMap = [ "1" : "blocker", "2" : "critical", "3" : "critical", "4" : "major", "5" : "major", "6" : "major", "7" : "minor", "8" : "minor", "9" : "trivial" ];

Ohh, but non works on module scope, so yes, it would be fine to fix this

but enum works fine: enum priorityMap = [ "1" : "blocker", "2" : "critical", "3" : "critical", "4" : "major", "5" : "major", "6" : "major", "7" : "minor", "8" : "minor", "9" : "trivial" ];

So it does... I didn't think of an enum AA ;) --047d7b41c0bafca60604eae4ba8e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">On 11 November 2013 20:14, Daniel Kozak <span dir=3D"ltr">= &lt;<a href=3D"mailto:kozzi11 gmail.com" target=3D"_blank">kozzi11 gmail.co= m</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_q= uote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l= eft:1px #ccc solid;padding-left:1ex"> <div class=3D"HOEnZb"><div class=3D"h5">On Monday, 11 November 2013 at 10:1= 3:02 UTC, Daniel Kozak wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> On Monday, 11 November 2013 at 10:11:18 UTC, Daniel Kozak wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> On Monday, 11 November 2013 at 08:30:32 UTC, Manu wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> immutable string[string] priorityMap =3D [<br> &quot;1&quot; : &quot;blocker&quot;,<br> &quot;2&quot; : &quot;critical&quot;,<br> &quot;3&quot; : &quot;critical&quot;,<br> &quot;4&quot; : &quot;major&quot;,<br> &quot;5&quot; : &quot;major&quot;,<br> &quot;6&quot; : &quot;major&quot;,<br> &quot;7&quot; : &quot;minor&quot;,<br> &quot;8&quot; : &quot;minor&quot;,<br> &quot;9&quot; : &quot;trivial&quot; ];<br> <br> main.d(56): Error: non-constant expression [&quot;1&quot;:&quot;blocker&quo= t;, &quot;2&quot;:&quot;critical&quot;,<br> &quot;3&quot;:&quot;critical&quot;, &quot;4&quot;:&quot;major&quot;, &quot;= 5&quot;:&quot;major&quot;, &quot;6&quot;:&quot;major&quot;, &quot;7&quot;:&= quot;minor&quot;,<br> &quot;8&quot;:&quot;minor&quot;, &quot;9&quot;:&quot;trivial&quot;]<br> <br> This is tedious, how long has it been now?<br> Seriously, static map&#39;s are super-important, they should be able to be = made<br> immutable, and also be able to be initialised.<br> <br> Maybe this could be factored into the improvements for 2.065?<br> </blockquote> <br> And even this works ok:<br> <br> immutable string[string] priorityMap =3D [<br> &quot;1&quot; : &quot;blocker&quot;,<br> &quot;2&quot; : &quot;critical&quot;,<br> &quot;3&quot; : &quot;critical&quot;,<br> &quot;4&quot; : &quot;major&quot;,<br> &quot;5&quot; : &quot;major&quot;,<br> &quot;6&quot; : &quot;major&quot;,<br> &quot;7&quot; : &quot;minor&quot;,<br> &quot;8&quot; : &quot;minor&quot;,<br> &quot;9&quot; : &quot;trivial&quot; ];<br> </blockquote> <br> Ohh, but non works on module scope, so yes, it would be fine to fix this<br=

<br></div></div> but enum works fine:<br> <br> enum priorityMap =3D [<div class=3D"HOEnZb"><div class=3D"h5"><br> =C2=A0 =C2=A0 &quot;1&quot; : &quot;blocker&quot;,<br> =C2=A0 =C2=A0 &quot;2&quot; : &quot;critical&quot;,<br> =C2=A0 =C2=A0 &quot;3&quot; : &quot;critical&quot;,<br> =C2=A0 =C2=A0 &quot;4&quot; : &quot;major&quot;,<br> =C2=A0 =C2=A0 &quot;5&quot; : &quot;major&quot;,<br> =C2=A0 =C2=A0 &quot;6&quot; : &quot;major&quot;,<br> =C2=A0 =C2=A0 &quot;7&quot; : &quot;minor&quot;,<br> =C2=A0 =C2=A0 &quot;8&quot; : &quot;minor&quot;,<br> =C2=A0 =C2=A0 &quot;9&quot; : &quot;trivial&quot; ];<br> </div></div></blockquote></div><br></div><div class=3D"gmail_extra">So it d= oes... I didn&#39;t think of an enum AA ;)</div></div> --047d7b41c0bafca60604eae4ba8e--
Nov 11 2013
prev sibling next sibling parent reply "Daniel Murphy" <yebblies nospamgmail.com> writes:
"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.
Nov 11 2013
next sibling parent "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Don" <x nospam.com> wrote in message 
news:bdmmimwuqsgphgprdngh forum.dlang.org...
 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.

Yeah, IIRC the missing piece is putting AAs in the data segment so they can cross from compile to run-time with out an aaliteral call. At least then we could use enum aas in runtime code without allocating. It would be great if we could make aa literals default to immutable (array literals too), and force adding .dup to get a mutable version.
Nov 12 2013
prev sibling next sibling parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"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’.
Jan 12 2014
next sibling parent "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Manu" <turkeyman gmail.com> wrote in message 
news:mailman.355.1389539511.15871.digitalmars-d puremagic.com...
 I'm often surprised that a semi-official fork has never appeared ;)

I don't agree with everything Walter does, but that doesn't mean I want his job.
 When is the next release meant to be? I saw comments in those bugs that it 
 was supposed to > be in December, but that seems too soon?

When all regressions are fixed + when Walter says so + when the moon is in the correct phase
Jan 12 2014
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/12/14 3:02 AM, Daniel Murphy wrote:
 "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’.

If we're refraining from or delaying pulling contributions for undue reasons we're doing something wrong. Andrei
Jan 12 2014
next sibling parent "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Andrei Alexandrescu"  wrote in message 
news:laugvv$2k3h$1 digitalmars.com...
 If we're refraining from or delaying pulling contributions for undue 
 reasons we're doing something wrong.

I don't know if it's undue or not, but https://github.com/D-Programming-Language/dmd/pull/2895 https://github.com/D-Programming-Language/dmd/pull/2924
Jan 12 2014
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/12/14 2:27 PM, Brad Anderson wrote:
 I had to get this off my chest even if it's unlikely to be
 adopted:

 http://wiki.dlang.org/Simplified_Release_Process_Proposal

cc Andrew Edwards Andrei
Jan 12 2014
prev sibling parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"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.
Jan 12 2014
parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Jakob Ovrum"  wrote in message news:whwxxduozvqjrcldmggt forum.dlang.org...
 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.

This used to be true, but now we can pass heap-allocated structs and classes from compile-time to run-time. The fact we can't do the same for AAs is an embarrassing limitation. It would have happened years ago if AAs weren't such a mess.
Jan 12 2014
parent "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Jakob Ovrum"  wrote in message news:yvvcvcfughejigooefua forum.dlang.org...
 This ability for class instances is fairly recent, but the same point 
 remains - being able to instantiate a class at compile-time and use it at 
 runtime is equally a tall order, not a fundamental feature, and it wasn't 
 a bug when it was absent.

I disagree. Being able to pass classes from ctfe to run-time is a fundamental feature of ctfe. AAs are even more important, as no ctfe is required to hit this limitation.
Jan 12 2014
prev sibling next sibling parent "Daniel Kozak" <kozzi11 gmail.com> writes:
On Monday, 11 November 2013 at 11:43:01 UTC, Dmitry Olshansky 
wrote:
 11-Nov-2013 15:06, Manu пишет:

    but enum works fine:

    enum priorityMap = [

         "1" : "blocker",
         "2" : "critical",
         "3" : "critical",
         "4" : "major",
         "5" : "major",
         "6" : "major",
         "7" : "minor",
         "8" : "minor",
         "9" : "trivial" ];


 So it does... I didn't think of an enum AA ;)

... copy pastes that literal everywhere, I'm sure you'll like it ;)

Yes, it is perfect :D
Nov 11 2013
prev sibling next sibling parent "simendsjo" <simendsjo gmail.com> writes:
On Monday, 11 November 2013 at 11:43:01 UTC, Dmitry Olshansky
wrote:
 11-Nov-2013 15:06, Manu пишет:

    but enum works fine:

    enum priorityMap = [

         "1" : "blocker",
         "2" : "critical",
         "3" : "critical",
         "4" : "major",
         "5" : "major",
         "6" : "major",
         "7" : "minor",
         "8" : "minor",
         "9" : "trivial" ];


 So it does... I didn't think of an enum AA ;)

... copy pastes that literal everywhere, I'm sure you'll like it ;)

Will it be copied even if you just use it ("1" in priorityMap), or only if you pass it around as a parameter or assign it to variables?
Nov 11 2013
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday, November 11, 2013 12:55:09 simendsjo wrote:
 On Monday, 11 November 2013 at 11:43:01 UTC, Dmitry Olshansky
=20
 wrote:
 11-Nov-2013 15:06, Manu =D0=BF=D0=B8=D1=88=D0=B5=D1=82:
    but enum works fine:
   =20
    enum priorityMap =3D [
   =20
         "1" : "blocker",
         "2" : "critical",
         "3" : "critical",
         "4" : "major",
         "5" : "major",
         "6" : "major",
         "7" : "minor",
         "8" : "minor",
         "9" : "trivial" ];
=20
 So it does... I didn't think of an enum AA ;)

... copy pastes that literal everywhere, I'm sure you'll like it ;)

Will it be copied even if you just use it ("1" in priorityMap), or only if you pass it around as a parameter or assign it to variables?

Every time you use an enum, it's replaced with its value. So, if an enu= m is an=20 AA, then that literal is copy-pasted everywhere that the enum is used. = So, it=20 would almost certainly be foolish to use it anywhere other than to assi= gn to a=20 variable (and then all of the operations are done on the variable). Rea= lly,=20 having an enum that's an AA is almost certainly a foolish thing to do. = It's=20 one case where the behavior of enums doesn't help and definitely hurts.= - Jonathan M Davis
Nov 11 2013
prev sibling next sibling parent "OneTwo" <onetwo example.com> writes:
enum - compile time constant
immutable - run time constant

thread about it was somewhere here
Nov 11 2013
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday, November 11, 2013 13:42:17 OneTwo wrote:
 enum - compile time constant
 immutable - run time constant

Not exactly. If they're global or static, then they both have to be known at compile time (though you can initialize an immutable global or static in a static constructor, which you can't do with an enum). The primary difference is that an immutable variable is actually a variable with a location in memory, where an enum is just a value that gets copy-pasted wherever it's used and is not associated with any particular location in memory. So, which you use tends to depend on whether you need it to be associated with a particular address in memory and whether you want its value to be copied everywhere. - Jonathan M Davis
Nov 11 2013
prev sibling next sibling parent "TheFlyingFiddle" <theflyingfiddle gmail.com> writes:
On Monday, 11 November 2013 at 12:14:10 UTC, Jonathan M Davis 
wrote:
 Every time you use an enum, it's replaced with its value. So, 
 if an enum is an
 AA, then that literal is copy-pasted everywhere that the enum 
 is used. So, it
 would almost certainly be foolish to use it anywhere other than 
 to assign to a
 variable (and then all of the operations are done on the 
 variable). Really,
 having an enum that's an AA is almost certainly a foolish thing 
 to do. It's
 one case where the behavior of enums doesn't help and 
 definitely hurts.

 - Jonathan M Davis

I have found it to be kind of usefull atleast when i'm only using the AA at compiletime. Like a simple vector swizzle like the code below. I store rgba/xyzw characters in the table with diffrent offsets into a static array. Vector!(s.length, T) opDispatch(string s)() if(s.length > 1) { Vector!(s.length, T) res; foreach(i; staticIota!(0, s.length)) { enum offset = swizzleTable[s[i]]; res.data[i] = data[offset]; } return res; } However with your statement above i'm now a little worried does this mean that the line enum offset = swizzleTable[s[i]]; will not be able to pick the correct constant at compiletime? And will instead do some runtime AA hash lookup?
Nov 11 2013
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Tuesday, November 12, 2013 01:07:21 TheFlyingFiddle wrote:
 On Monday, 11 November 2013 at 12:14:10 UTC, Jonathan M Davis
 
 wrote:
 Every time you use an enum, it's replaced with its value. So,
 if an enum is an
 AA, then that literal is copy-pasted everywhere that the enum
 is used. So, it
 would almost certainly be foolish to use it anywhere other than
 to assign to a
 variable (and then all of the operations are done on the
 variable). Really,
 having an enum that's an AA is almost certainly a foolish thing
 to do. It's
 one case where the behavior of enums doesn't help and
 definitely hurts.
 
 - Jonathan M Davis

I have found it to be kind of usefull atleast when i'm only using the AA at compiletime. Like a simple vector swizzle like the code below. I store rgba/xyzw characters in the table with diffrent offsets into a static array. Vector!(s.length, T) opDispatch(string s)() if(s.length > 1) { Vector!(s.length, T) res; foreach(i; staticIota!(0, s.length)) { enum offset = swizzleTable[s[i]]; res.data[i] = data[offset]; } return res; } However with your statement above i'm now a little worried does this mean that the line enum offset = swizzleTable[s[i]]; will not be able to pick the correct constant at compiletime? And will instead do some runtime AA hash lookup?

All enum's must be known at compile time. They are never calculated at runtime. It's the _value_ of an enum that gets copy-pasted, not its text. So, if you have enum offset = swizzleTable[s[i]]; then the result will be calculated at compile time. Whether calculating it is at all efficient is quite another matter, but the calculation will be done at compile time. - Jonathan M Davis
Nov 11 2013
prev sibling next sibling parent "Don" <x nospam.com> writes:
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.
Nov 12 2013
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--047d7b4725a8a9a07d04efbe0eb8
Content-Type: text/plain; charset=UTF-8

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",

 "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? :) --047d7b4725a8a9a07d04efbe0eb8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 1= 1 November 2013 21:38, Daniel Murphy <span dir=3D"ltr">&lt;<a href=3D"mailt= o:yebblies nospamgmail.com" target=3D"_blank">yebblies nospamgmail.com</a>&= gt;</span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex">&quot;Manu&quot; &lt;<a href=3D"mailto:turke= yman gmail.com">turkeyman gmail.com</a>&gt; wrote in message<br> news:mailman.355.1384158631.9546.digitalmars-d puremagic.com...<br> <div class=3D"im">&gt; immutable string[string] priorityMap =3D [<br> &gt; &quot;1&quot; : &quot;blocker&quot;,<br> &gt; &quot;2&quot; : &quot;critical&quot;,<br> &gt; &quot;3&quot; : &quot;critical&quot;,<br> &gt; &quot;4&quot; : &quot;major&quot;,<br> &gt; &quot;5&quot; : &quot;major&quot;,<br> &gt; &quot;6&quot; : &quot;major&quot;,<br> &gt; &quot;7&quot; : &quot;minor&quot;,<br> &gt; &quot;8&quot; : &quot;minor&quot;,<br> &gt; &quot;9&quot; : &quot;trivial&quot; ];<br> &gt;<br> &gt; main.d(56): Error: non-constant expression [&quot;1&quot;:&quot;blocke= r&quot;, &quot;2&quot;:&quot;critical&quot;,<br> &gt; &quot;3&quot;:&quot;critical&quot;, &quot;4&quot;:&quot;major&quot;, &= quot;5&quot;:&quot;major&quot;, &quot;6&quot;:&quot;major&quot;, &quot;7&qu= ot;:&quot;minor&quot;,<br> &gt; &quot;8&quot;:&quot;minor&quot;, &quot;9&quot;:&quot;trivial&quot;]<br=

&gt; This is tedious, how long has it been now?<br> &gt; Seriously, static map&#39;s are super-important, they should be able t= o be<br> &gt; made<br> &gt; immutable, and also be able to be initialised.<br> &gt;<br> &gt; Maybe this could be factored into the improvements for 2.065?<br> &gt;<br> <br> </div>I think yes, it can be done for 2.065. =C2=A0Someone remind me if we = get close<br> and it isn&#39;t done yet.<br></blockquote><div><br></div><div>I&#39;ve jus= t run into this again today. It&#39;s still very annoying.</div><div>Consid= er this a reminder? :)</div></div></div></div> --047d7b4725a8a9a07d04efbe0eb8--
Jan 11 2014
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--001a11c2aa6a5f042804efbe1cdd
Content-Type: text/plain; charset=UTF-8

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?

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. --001a11c2aa6a5f042804efbe1cdd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 1= 2 November 2013 18:09, Don <span dir=3D"ltr">&lt;<a href=3D"mailto:x nospam= .com" target=3D"_blank">x nospam.com</a>&gt;</span> wrote:<br><blockquote c= lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;= padding-left:1ex"> <div class=3D"HOEnZb"><div class=3D"h5">On Monday, 11 November 2013 at 11:3= 9:06 UTC, Daniel Murphy wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> &quot;Manu&quot; &lt;<a href=3D"mailto:turkeyman gmail.com" target=3D"_blan= k">turkeyman gmail.com</a>&gt; wrote in message<br> news:mailman.355.1384158631.<u></u>9546.digitalmars-d puremagic.<u></u>com.= ..<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> immutable string[string] priorityMap =3D [<br> &quot;1&quot; : &quot;blocker&quot;,<br> &quot;2&quot; : &quot;critical&quot;,<br> &quot;3&quot; : &quot;critical&quot;,<br> &quot;4&quot; : &quot;major&quot;,<br> &quot;5&quot; : &quot;major&quot;,<br> &quot;6&quot; : &quot;major&quot;,<br> &quot;7&quot; : &quot;minor&quot;,<br> &quot;8&quot; : &quot;minor&quot;,<br> &quot;9&quot; : &quot;trivial&quot; ];<br> <br> main.d(56): Error: non-constant expression [&quot;1&quot;:&quot;blocker&quo= t;, &quot;2&quot;:&quot;critical&quot;,<br> &quot;3&quot;:&quot;critical&quot;, &quot;4&quot;:&quot;major&quot;, &quot;= 5&quot;:&quot;major&quot;, &quot;6&quot;:&quot;major&quot;, &quot;7&quot;:&= quot;minor&quot;,<br> &quot;8&quot;:&quot;minor&quot;, &quot;9&quot;:&quot;trivial&quot;]<br> <br> This is tedious, how long has it been now?<br> Seriously, static map&#39;s are super-important, they should be able to be = made<br> immutable, and also be able to be initialised.<br> <br> Maybe this could be factored into the improvements for 2.065?<br> <br> </blockquote> <br> I think yes, it can be done for 2.065. =C2=A0Someone remind me if we get cl= ose<br> and it isn&#39;t done yet.<br> </blockquote> <br> <br></div></div> IIRC the poor performance of array literals and AA literals is because they= &#39;re not always literals, sometimes they are variables (!) and the compi= ler assumes the worst case. You are allowed to write:<br> <br> void foo(int some_param)<br> {<br> =C2=A0 =C2=A0 immutable string[int] =3D [ 1: &quot;abc&quot;, some_param: &= quot;def&quot;];<br> }<br> <br> I wish we could get rid of that silliness entirely.<br> <br> <br> If the members are compile-time expressions, you probably want to mark the = variable as static const/static immutable.<br> </blockquote></div></div><div class=3D"gmail_extra"><br></div><div class=3D= "gmail_extra">I&#39;ve also had this thought. Logically, you shouldn&#39;t = need to declare an immutable thing static (although currently, you do), alt= hough the advantage would be a guaranteed compile error if you try to do so= mething silly like initialise from a variable.</div> </div> --001a11c2aa6a5f042804efbe1cdd--
Jan 11 2014
prev sibling next sibling parent "Orvid King" <blah38621 gmail.com> writes:
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.
Jan 11 2014
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--089e0153884813832004efbed6bc
Content-Type: text/plain; charset=UTF-8

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.

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. --089e0153884813832004efbed6bc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 1= 2 January 2014 14:29, Orvid King <span dir=3D"ltr">&lt;<a href=3D"mailto:bl= ah38621 gmail.com" target=3D"_blank">blah38621 gmail.com</a>&gt;</span> wro= te:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-= left:1px #ccc solid;padding-left:1ex"> <div class=3D"HOEnZb"><div class=3D"h5">On Sat, 11 Jan 2014 22:08:25 -0600,= Manu &lt;<a href=3D"mailto:turkeyman gmail.com" target=3D"_blank">turkeyma= n gmail.com</a>&gt; wrote:<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> On 12 November 2013 18:09, Don &lt;<a href=3D"mailto:x nospam.com" target= =3D"_blank">x nospam.com</a>&gt; wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> <br> On Monday, 11 November 2013 at 11:39:06 UTC, Daniel Murphy wrote:<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> <br> &quot;Manu&quot; &lt;<a href=3D"mailto:turkeyman gmail.com" target=3D"_blan= k">turkeyman gmail.com</a>&gt; wrote in message<br> <br> news:mailman.355.1384158631.<u></u>9546.digitalmars-d puremagic.<u></u>com.= ..<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> <br> immutable string[string] priorityMap =3D [<br> <br> &quot;1&quot; : &quot;blocker&quot;,<br> <br> &quot;2&quot; : &quot;critical&quot;,<br> <br> &quot;3&quot; : &quot;critical&quot;,<br> <br> &quot;4&quot; : &quot;major&quot;,<br> <br> &quot;5&quot; : &quot;major&quot;,<br> <br> &quot;6&quot; : &quot;major&quot;,<br> <br> &quot;7&quot; : &quot;minor&quot;,<br> <br> &quot;8&quot; : &quot;minor&quot;,<br> <br> &quot;9&quot; : &quot;trivial&quot; ];<br> <br> <br> <br> main.d(56): Error: non-constant expression [&quot;1&quot;:&quot;blocker&quo= t;, &quot;2&quot;:&quot;critical&quot;,<br> <br> &quot;3&quot;:&quot;critical&quot;, &quot;4&quot;:&quot;major&quot;, &quot;= 5&quot;:&quot;major&quot;, &quot;6&quot;:&quot;major&quot;, &quot;7&quot;:&= quot;minor&quot;,<br> <br> &quot;8&quot;:&quot;minor&quot;, &quot;9&quot;:&quot;trivial&quot;]<br> <br> <br> <br> This is tedious, how long has it been now?<br> <br> Seriously, static map&#39;s are super-important, they should be able to be = made<br> <br> immutable, and also be able to be initialised.<br> <br> <br> <br> Maybe this could be factored into the improvements for 2.065?<br> <br> <br> <br> </blockquote> <br> <br> <br> I think yes, it can be done for 2.065. =C2=A0Someone remind me if we get cl= ose<br> <br> and it isn&#39;t done yet.<br> <br> </blockquote> <br> <br> <br> <br> <br> IIRC the poor performance of array literals and AA literals is because they= &#39;re not always &gt;&gt;literals, sometimes they are variables (!) and t= he compiler assumes the worst case. You are &gt;&gt;allowed to write:<br> <br> <br> <br> void foo(int some_param)<br> <br> {<br> <br> =C2=A0 =C2=A0immutable string[int] =3D [ 1: &quot;abc&quot;, some_param: &q= uot;def&quot;];<br> <br> }<br> <br> <br> <br> I wish we could get rid of that silliness entirely.<br> <br> <br> <br> <br> <br> If the members are compile-time expressions, you probably want to mark the = variable as static &gt;&gt;const/static immutable.<br> <br> </blockquote> <br> I&#39;ve also had this thought. Logically, you shouldn&#39;t need to declar= e an immutable thing static &gt;(although currently, you do), although the = advantage would be a guaranteed compile error if you try &gt;to do somethin= g silly like initialise from a variable.<br> </blockquote> <br></div></div> I would disagree with that statement, because it is my understanding of imm= utable that it merely means that the value is not modified after it is init= ialized, 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.<br> </blockquote></div><br></div><div class=3D"gmail_extra">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&#39;s no need to re-allocate+initialise it on every call to the func= tion.</div> </div> --089e0153884813832004efbed6bc--
Jan 11 2014
prev sibling next sibling parent "Jakob Ovrum" <jakobovrum gmail.com> writes:
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.
Jan 11 2014
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--001a1133096428cd6004efbf2429
Content-Type: text/plain; charset=UTF-8

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. --001a1133096428cd6004efbf2429 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 1= 2 January 2014 15:05, Jakob Ovrum <span dir=3D"ltr">&lt;<a href=3D"mailto:j= akobovrum gmail.com" target=3D"_blank">jakobovrum gmail.com</a>&gt;</span> = wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><div class=3D"im">On Sunday, 12 January 2014= at 04:05:02 UTC, Manu wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> I&#39;ve just run into this again today. It&#39;s still very annoying.<br> Consider this a reminder? :)<br> </blockquote> <br></div> Do you even understand the problem? This is an extremely complicated thing = that you are asking, you can&#39;t do anything like it in any other program= ming language that I&#39;m aware of. We have been making progress in making= it work over the years, but for AAs it&#39;s at an impasse due to how AAs = are implemented in the compiler.<br> <br> This kind of nagging is not helping anyone, it&#39;s just annoying.<br> </blockquote></div><br></div><div class=3D"gmail_extra">No I don&#39;t unde= rstand the problem. What I do know is that Daniel said to remind him, so I = did.</div><div class=3D"gmail_extra">He made it sound like it was quite fix= able-able in November.</div> </div> --001a1133096428cd6004efbf2429--
Jan 11 2014
prev sibling next sibling parent "Jakob Ovrum" <jakobovrum gmail.com> writes:
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.
Jan 12 2014
prev sibling next sibling parent "Jakob Ovrum" <jakobovrum gmail.com> writes:
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...
Jan 12 2014
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--001a11c2a20cc69f4704efc75f75
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 12 January 2014 21:02, Daniel Murphy <yebbliesnospam gmail.com> wrote:

 "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=E2=80=99t inspire me to work on =

 bugs=E2=80=99.

I'm often surprised that a semi-official fork has never appeared ;) When is the next release meant to be? I saw comments in those bugs that it was supposed to be in December, but that seems too soon? --001a11c2a20cc69f4704efc75f75 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 1= 2 January 2014 21:02, Daniel Murphy <span dir=3D"ltr">&lt;<a href=3D"mailto= :yebbliesnospam gmail.com" target=3D"_blank">yebbliesnospam gmail.com</a>&g= t;</span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex">&quot;Manu&quot; &lt;<a href=3D"mailto:turke= yman gmail.com" target=3D"_blank">turkeyman gmail.com</a>&gt; wrote in mess= age news:mailman.334.1389499497.<u></u>15871.digitalmars-d puremagic.<u></u=
com...<div class=3D"im">

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> I&#39;ve just run into this again today. It&#39;s still very annoying.<br> Consider this a reminder? :)<br> </blockquote> <br></div> AAs should be rolled back first, and these have been sitting there for a co= uple of months.<br> <br> <a href=3D"https://github.com/D-Programming-Language/dmd/pull/2856" target= =3D"_blank">https://github.com/D-<u></u>Programming-Language/dmd/pull/<u></= u>2856</a><br> <a href=3D"https://github.com/D-Programming-Language/druntime/pull/668" tar= get=3D"_blank">https://github.com/D-<u></u>Programming-Language/druntime/<u=
</u>pull/668</a><br>

Walter has decided that this coming release will only be bugfixes... kind o= f a useless thing to do for an open source project, as him refusing to revi= ew/merge my enhancement pulls doesn=E2=80=99t inspire me to work on =E2=80= =98actual bugs=E2=80=99.<br> </blockquote><div><br></div><div>I&#39;m often surprised that a semi-offici= al fork has never appeared ;)</div><div><br></div><div>When is the next rel= ease meant to be? I saw comments in those bugs that it was supposed to be i= n December, but that seems too soon?</div> </div></div></div> --001a11c2a20cc69f4704efc75f75--
Jan 12 2014
prev sibling next sibling parent "Jakob Ovrum" <jakobovrum gmail.com> writes:
On Sunday, 12 January 2014 at 14:30:42 UTC, Daniel Murphy wrote:
 This used to be true, but now we can pass heap-allocated 
 structs and classes from compile-time to run-time.  The fact we 
 can't do the same for AAs is an embarrassing limitation.

This ability for class instances is fairly recent, but the same point remains - being able to instantiate a class at compile-time and use it at runtime is equally a tall order, not a fundamental feature, and it wasn't a bug when it was absent.
Jan 12 2014
prev sibling next sibling parent "Brad Anderson" <eco gnuk.net> writes:
On Sunday, 12 January 2014 at 16:48:08 UTC, Andrei Alexandrescu
wrote:
 On 1/12/14 3:02 AM, Daniel Murphy wrote:
 "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’.

If we're refraining from or delaying pulling contributions for undue reasons we're doing something wrong. Andrei

The Release Process on the wiki[1] does not have a method for a bugfix only release so it's definitely a problem. Both bugfixes and features get merged into master. The release process forbids cherry-picking between branches (some rationale for this rule would be nice; it feels like a mistake to me) so that can't be used to solve the problem. I don't think there is a way to do a bugfix only release without cherry-picking. If it were me, I'd just would have had both bugfixes and features merge into master as described by the release process and have a 2.065 branch which a single person is responsible for cherry-picking bugfixes into (alternatively you could have whoever merges the bugfix into master do it). Frankly, I think the described Release Process is much more complicated than it needs to be. Fundamentally you only need two branches at any given time: master and a release branch which only exists after the feature freeze takes place for an upcoming release (post-release the branch gets tagged, merged back into master[2], and deleted). It's a shame Github doesn't let you target multiple branches with a pull request. That'd be a nice workflow during the short lived feature freeze window. 1. http://wiki.dlang.org/Release_Process 2. Which, I found out by chance, never happens: https://github.com/D-Programming-Language/dmd/pull/3080 This is very bad as commits can easily get lost though I question whether the release branch should ever be committed to directly.
Jan 12 2014
prev sibling next sibling parent "Brad Anderson" <eco gnuk.net> writes:
On Sunday, 12 January 2014 at 19:45:15 UTC, Brad Anderson wrote:
 On Sunday, 12 January 2014 at 16:48:08 UTC, Andrei Alexandrescu
 wrote:
 If we're refraining from or delaying pulling contributions for 
 undue reasons we're doing something wrong.

 Andrei

The Release Process on the wiki[1] does not have a method for a bugfix only release so it's definitely a problem. Both bugfixes and features get merged into master. The release process forbids cherry-picking between branches (some rationale for this rule would be nice; it feels like a mistake to me) so that can't be used to solve the problem. I don't think there is a way to do a bugfix only release without cherry-picking. If it were me, I'd just would have had both bugfixes and features merge into master as described by the release process and have a 2.065 branch which a single person is responsible for cherry-picking bugfixes into (alternatively you could have whoever merges the bugfix into master do it). Frankly, I think the described Release Process is much more complicated than it needs to be. Fundamentally you only need two branches at any given time: master and a release branch which only exists after the feature freeze takes place for an upcoming release (post-release the branch gets tagged, merged back into master[2], and deleted).

I had to get this off my chest even if it's unlikely to be adopted: http://wiki.dlang.org/Simplified_Release_Process_Proposal
Jan 12 2014
prev sibling parent "Brad Anderson" <eco gnuk.net> writes:
On Sunday, 12 January 2014 at 23:37:12 UTC, Andrei Alexandrescu
wrote:
 On 1/12/14 2:27 PM, Brad Anderson wrote:
 I had to get this off my chest even if it's unlikely to be
 adopted:

 http://wiki.dlang.org/Simplified_Release_Process_Proposal

cc Andrew Edwards Andrei

Done.
Jan 12 2014