www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - AA literals/initialisation

reply Manu <turkeyman gmail.com> writes:
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?
Nov 11 2013
next sibling parent reply "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
parent Manu <turkeyman gmail.com> writes:
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" ];
   }
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 "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
parent reply "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
parent reply Manu <turkeyman gmail.com> writes:
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 ;)
Nov 11 2013
next sibling 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
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 parent reply "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
next sibling 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 parent reply 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 ;)


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


=20
 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
parent reply "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
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 parent reply "OneTwo" <onetwo example.com> writes:
enum - compile time constant
immutable - run time constant

thread about it was somewhere here
Nov 11 2013
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 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 reply "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
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 Manu <turkeyman gmail.com> writes:
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.
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 parent Manu <turkeyman gmail.com> writes:
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.
Jan 11 2014
prev sibling parent reply Manu <turkeyman gmail.com> writes:
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? :)
Jan 11 2014
next sibling parent reply "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
next sibling parent reply Manu <turkeyman gmail.com> writes:
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.
Jan 11 2014
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 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 "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 

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
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 reply "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
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 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 reply Manu <turkeyman gmail.com> writes:
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 =


=E2=80=98actual

 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?
Jan 12 2014
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 reply "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
parent reply "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
parent reply 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
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