www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Associative Arrays in the data segment

reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
One long-standing issue with AAs has been that you can't generate constant 
ones at compile time and access them at run-time.  Workarounds are 
available, like initializing them in static this or using horribly 
inefficient enum AAs.

I've opened https://github.com/D-Programming-Language/dmd/pull/4571 which 
allows code like this:

immutable int[int] aa = [1 : 7, 3 : 2];

void main()
{
    assert(aa[1] == 7);
    assert(aa[3] == 2);
}

It only works with integral types of at most 32-bits at the moment, but most 
built-in types are fairly easy to support.  The downside is requires 
re-implementing druntime's AA and hashing algorithms in the compiler, and 
keeping them in sync when either changes.

I think it's worthwhile, even if only integral and string keys are supported 
for now.  That would cover 99% of my AA use.

Is anybody else interested in seeing this in the next release?
Apr 10 2015
next sibling parent reply "Andrea Fontana" <mail example.com> writes:
On Friday, 10 April 2015 at 07:54:44 UTC, Daniel Murphy wrote:

 One long-standing issue with AAs has been that you can't 
 generate constant ones at compile time and access them at 
 run-time.  Workarounds are available, like initializing them in 
 static this or using horribly inefficient enum AAs.

 I've opened 
 https://github.com/D-Programming-Language/dmd/pull/4571 which 
 allows code like this:

 immutable int[int] aa = [1 : 7, 3 : 2];

 void main()
 {
    assert(aa[1] == 7);
    assert(aa[3] == 2);
 }

 It only works with integral types of at most 32-bits at the 
 moment, but most built-in types are fairly easy to support.  
 The downside is requires re-implementing druntime's AA and 
 hashing algorithms in the compiler, and keeping them in sync 
 when either changes.

 I think it's worthwhile, even if only integral and string keys 
 are supported for now.  That would cover 99% of my AA use.

 Is anybody else interested in seeing this in the next release?


Why not 64bit integers?
Apr 10 2015
parent "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Andrea Fontana"  wrote in message 
news:nrlbhbhqutcmuyzkmspx forum.dlang.org...


 Why not 64bit integers?


Integers <= 32 bits have a trivial hash implementation (the value is the 
hash) so I did them first.  64-bit ints, strings, arrays etc need the 
multi-byte hash which I haven't gotten around to yet.
Apr 10 2015
prev sibling next sibling parent "Daniel Kozak" <kozzi11 gmail.com> writes:
On Friday, 10 April 2015 at 07:54:44 UTC, Daniel Murphy wrote:

 One long-standing issue with AAs has been that you can't 
 generate constant ones at compile time and access them at 
 run-time.  Workarounds are available, like initializing them in 
 static this or using horribly inefficient enum AAs.

 I've opened 
 https://github.com/D-Programming-Language/dmd/pull/4571 which 
 allows code like this:

 immutable int[int] aa = [1 : 7, 3 : 2];

 void main()
 {
    assert(aa[1] == 7);
    assert(aa[3] == 2);
 }

 It only works with integral types of at most 32-bits at the 
 moment, but most built-in types are fairly easy to support.  
 The downside is requires re-implementing druntime's AA and 
 hashing algorithms in the compiler, and keeping them in sync 
 when either changes.

 I think it's worthwhile, even if only integral and string keys 
 are supported for now.  That would cover 99% of my AA use.

 Is anybody else interested in seeing this in the next release?


this would be awesome
Apr 10 2015
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2015-04-10 09:54, Daniel Murphy wrote:


 Is anybody else interested in seeing this in the next release?


Yes. Will there be the same limitations on the values as on the keys?

-- 
/Jacob Carlborg
Apr 10 2015
parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Jacob Carlborg"  wrote in message news:mg8296$q6r$1 digitalmars.com...


 Yes. Will there be the same limitations on the values as on the keys?


No, values can be anything that is semantically valid and can currently be 
put in the data segment.  The currently limited selection of key types is 
because the hashing needs to be re-implemented in the compiler.

eg Object[int] and int[int][int] both work fine.
Apr 10 2015
parent Jacob Carlborg <doob me.com> writes:
On 2015-04-10 11:19, Daniel Murphy wrote:


 No, values can be anything that is semantically valid and can currently
 be put in the data segment.  The currently limited selection of key
 types is because the hashing needs to be re-implemented in the compiler.

 eg Object[int] and int[int][int] both work fine.


Cool :)

-- 
/Jacob Carlborg
Apr 10 2015
prev sibling next sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Fri, 10 Apr 2015 17:54:47 +1000, Daniel Murphy wrote:


 One long-standing issue with AAs has been that you can't generate
 constant ones at compile time and access them at run-time.  Workarounds
 are available, like initializing them in static this or using horribly
 inefficient enum AAs.
=20
 I've opened https://github.com/D-Programming-Language/dmd/pull/4571
 which allows code like this:
=20
 immutable int[int] aa =3D [1 : 7, 3 : 2];
=20
 void main()
 {
     assert(aa[1] =3D=3D 7);
     assert(aa[3] =3D=3D 2);
 }
=20
 It only works with integral types of at most 32-bits at the moment, but
 most built-in types are fairly easy to support.  The downside is
 requires re-implementing druntime's AA and hashing algorithms in the
 compiler, and keeping them in sync when either changes.
=20
 I think it's worthwhile, even if only integral and string keys are
 supported for now.  That would cover 99% of my AA use.
=20
 Is anybody else interested in seeing this in the next release?


this has a majour drawback, methinks: an inability to change AA=20
implementation without fixing the compiler too. i.e. i can't no longer to=20
simply rewrite the relevant parts of druntime (change hashing function,=20
for example) and be happy.=
Apr 10 2015
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 4/10/15 9:04 AM, ketmar wrote:

 On Fri, 10 Apr 2015 17:54:47 +1000, Daniel Murphy wrote:



 It only works with integral types of at most 32-bits at the moment, but
 most built-in types are fairly easy to support.  The downside is
 requires re-implementing druntime's AA and hashing algorithms in the
 compiler, and keeping them in sync when either changes.





 this has a majour drawback, methinks: an inability to change AA
 implementation without fixing the compiler too. i.e. i can't no longer to
 simply rewrite the relevant parts of druntime (change hashing function,
 for example) and be happy.


I agree with ketmar, If the compiler implements this, then you cannot 
play with the implementation of AA at all without changing the compiler.

I'd rather see the compiler treat AA as fully library type, and be able 
to build AA at compile time because the code is sane.

-Steve
Apr 10 2015
next sibling parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Steven Schveighoffer"  wrote in message 
news:mg8ihs$1at6$1 digitalmars.com...


 this has a majour drawback, methinks: an inability to change AA
 implementation without fixing the compiler too. i.e. i can't no longer 
 to
 simply rewrite the relevant parts of druntime (change hashing function,
 for example) and be happy.


 I agree with ketmar, If the compiler implements this, then you cannot play 
 with the implementation of AA at all without changing the compiler.


The AA implementation has changed once in the time I've been involved with 
D.  I don't see this as a big concern.


 I'd rather see the compiler treat AA as fully library type, and be able to 
 build AA at compile time because the code is sane.


Who wouldn't?  But realistically, how many more years until that happens?
Apr 10 2015
next sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 4/10/15 9:44 AM, Daniel Murphy wrote:

 "Steven Schveighoffer"  wrote in message
 news:mg8ihs$1at6$1 digitalmars.com...


 this has a majour drawback, methinks: an inability to change AA
 implementation without fixing the compiler too. i.e. i can't no


 longer > to

 simply rewrite the relevant parts of druntime (change hashing function,
 for example) and be happy.


 I agree with ketmar, If the compiler implements this, then you cannot
 play with the implementation of AA at all without changing the compiler.


 The AA implementation has changed once in the time I've been involved
 with D.  I don't see this as a big concern.


It's all the rage these days, Walter just started a thread on it ;)

But the issue I see is that this is a step BACKWARDS. We want to move to 
more possibility of customization, not less. Subtle differences in 
compiler/library implementation are the stuff nightmare bugs are made of.


 I'd rather see the compiler treat AA as fully library type, and be
 able to build AA at compile time because the code is sane.


 Who wouldn't?  But realistically, how many more years until that happens?


I think it's possible now, but nobody has been able to exactly duplicate 
certain aspects of the builtin AA. I may take a stab at it. We also had 
a horrible experience of "half-library half magic" type a few years ago.

But the real answer is, as soon as someone does it who has 
Walter's/Kenji's/your ear, we can create an AA, and fix the compiler to 
use and support it. It needs an advocate (who is willing to do the hard 
work).

-Steve
Apr 10 2015
parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Steven Schveighoffer"  wrote in message 
news:mg8ln4$1dtb$1 digitalmars.com...


 It's all the rage these days, Walter just started a thread on it ;)


Thread != activity.


 But the issue I see is that this is a step BACKWARDS. We want to move to 
 more possibility of customization, not less. Subtle differences in 
 compiler/library implementation are the stuff nightmare bugs are made of.


It lets us do something we currently can't do but want to, at the cost of 
making something we could do but haven't for years slightly harder.

If somebody really wants to improve the runtime AA implementation, they can
a) Update the compiler code to do the same thing
b) Ask me and I'll do it

Not being able to put AAs in the data segment is a stupid limitation that we 
should have fixed years ago.


 I think it's possible now, but nobody has been able to exactly duplicate 
 certain aspects of the builtin AA. I may take a stab at it. We also had a 
 horrible experience of "half-library half magic" type a few years ago.


The only positive thing that's made it into master in the last few years is 
rolling back the AA implementation.


 But the real answer is, as soon as someone does it who has 
 Walter's/Kenji's/your ear, we can create an AA, and fix the compiler to 
 use and support it. It needs an advocate (who is willing to do the hard 
 work).


I'm not holding my breath.
Apr 10 2015
next sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 4/10/15 10:20 AM, Daniel Murphy wrote:

 "Steven Schveighoffer"  wrote in message
 news:mg8ln4$1dtb$1 digitalmars.com...


 It's all the rage these days, Walter just started a thread on it ;)


 Thread != activity.


Well, it was a call to action by the language designer "here's a fun 
project anyone can do". Would be a shame for an unsuspecting person to 
do that, and then find out "oh, we can't use your work, because the 
compiler has an implementation already, and (insert some wrinkle why 
it's too difficult to update the compiler version to do what yours does)"


 But the issue I see is that this is a step BACKWARDS. We want to move
 to more possibility of customization, not less. Subtle differences in
 compiler/library implementation are the stuff nightmare bugs are made of.


 It lets us do something we currently can't do but want to, at the cost
 of making something we could do but haven't for years slightly harder.


Yes, I understand this. But I'm very firmly against putting more magic 
into the compiler. How many bugs or barriers to improvement are root 
caused by compiler magic treatment of something?


 If somebody really wants to improve the runtime AA implementation, they can
 a) Update the compiler code to do the same thing
 b) Ask me and I'll do it

 Not being able to put AAs in the data segment is a stupid limitation
 that we should have fixed years ago.


There are many stupid limitations that should have been fixed years ago. 
And I don't disagree this is one of them. I just disagree that this is a 
"fix". It's quite literally the introduction of a new problem that we 
don't need.


 I think it's possible now, but nobody has been able to exactly
 duplicate certain aspects of the builtin AA. I may take a stab at it.
 We also had a horrible experience of "half-library half magic" type a
 few years ago.


 The only positive thing that's made it into master in the last few years
 is rolling back the AA implementation.


No, the most significant change is making it so opEquals is used instead 
of opCmp for key lookup. And that was like pulling teeth.


 But the real answer is, as soon as someone does it who has
 Walter's/Kenji's/your ear, we can create an AA, and fix the compiler
 to use and support it. It needs an advocate (who is willing to do the
 hard work).


 I'm not holding my breath.


Clearly :)

-Steve
Apr 10 2015
parent "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Steven Schveighoffer"  wrote in message 
news:mg8nd3$1fq5$1 digitalmars.com...


 Well, it was a call to action by the language designer "here's a fun 
 project anyone can do". Would be a shame for an unsuspecting person to do 
 that, and then find out "oh, we can't use your work, because the compiler 
 has an implementation already, and (insert some wrinkle why it's too 
 difficult to update the compiler version to do what yours does)"


You're overestimating the difficulty of changing the implementation in the 
compiler.


 Yes, I understand this. But I'm very firmly against putting more magic 
 into the compiler. How many bugs or barriers to improvement are root 
 caused by compiler magic treatment of something?


Not that many?  How many improvements don't happen despite lack of barriers?


 There are many stupid limitations that should have been fixed years ago. 
 And I don't disagree this is one of them. I just disagree that this is a 
 "fix". It's quite literally the introduction of a new problem that we 
 don't need.


It's trading one problem for another.  Current problem: feature doesn't 
work.  New problem: somebody might have more trouble doing something they 
probably won't do anyway.  It's a win.
Apr 10 2015
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/10/15 7:20 AM, Daniel Murphy wrote:

 "Steven Schveighoffer"  wrote in message
 news:mg8ln4$1dtb$1 digitalmars.com...


 It's all the rage these days, Walter just started a thread on it ;)


 Thread != activity.


 But the issue I see is that this is a step BACKWARDS. We want to move
 to more possibility of customization, not less. Subtle differences in
 compiler/library implementation are the stuff nightmare bugs are made of.


 It lets us do something we currently can't do but want to, at the cost
 of making something we could do but haven't for years slightly harder.

 If somebody really wants to improve the runtime AA implementation, they can
 a) Update the compiler code to do the same thing
 b) Ask me and I'll do it

 Not being able to put AAs in the data segment is a stupid limitation
 that we should have fixed years ago.


 I think it's possible now, but nobody has been able to exactly
 duplicate certain aspects of the builtin AA. I may take a stab at it.
 We also had a horrible experience of "half-library half magic" type a
 few years ago.


 The only positive thing that's made it into master in the last few years
 is rolling back the AA implementation.


 But the real answer is, as soon as someone does it who has
 Walter's/Kenji's/your ear, we can create an AA, and fix the compiler
 to use and support it. It needs an advocate (who is willing to do the
 hard work).


 I'm not holding my breath.


Sadly I'm among the folks who aren't jazzed by this. It seems like an 
evolutionary backward step of only short-lived value. It's telling that 
some of the supporting arguments count on bad things not improving.

Andrei
Apr 10 2015
parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Andrei Alexandrescu"  wrote in message 
news:mg8s3d$1jn5$1 digitalmars.com...


 Sadly I'm among the folks who aren't jazzed by this. It seems like an 
 evolutionary backward step of only short-lived value. It's telling that 
 some of the supporting arguments count on bad things not improving.


If I'd been saying this three years ago I would have been right.  We should 
move towards something better, instead of sitting still and waiting for 
perfect.
Apr 10 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/10/15 9:15 AM, Daniel Murphy wrote:

 "Andrei Alexandrescu"  wrote in message
 news:mg8s3d$1jn5$1 digitalmars.com...


 Sadly I'm among the folks who aren't jazzed by this. It seems like an
 evolutionary backward step of only short-lived value. It's telling
 that some of the supporting arguments count on bad things not improving.


 If I'd been saying this three years ago I would have been right.  We
 should move towards something better, instead of sitting still and
 waiting for perfect.


Can you make a salient argument that this is a step in the right 
direction? In that case what's the vision for future steps? Thanks! -- 
Andrei
Apr 10 2015
parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Andrei Alexandrescu"  wrote in message 
news:mg94od$1v4g$1 digitalmars.com...


 Can you make a salient argument that this is a step in the right 
 direction? In that case what's the vision for future steps? Thanks! -- 
 Andrei


This approach makes the common cases of AAs in the data segment work.  This 
enables a very useful idiom of defining a constant lookup table and using it 
at runtime to map values.

The hashing and AA implementations that need to be replicated in the 
compiler are trivial, and easily updated if anybody does change the druntime 
implementation.  At worst it's pretty much a copy-paste from the druntime 
sources.  And as I've said, I'm happy provide a matching dmd implementation 
of anybody's new druntime implementation.

A future library AA implementation would not be complicated by this patch, 
because the code in this patch is only reached when an AA literal survives 
until codegen.  A library AA would lower the AA literal to some other 
construct before codegen.

This is a step in the right direction because it will make the common cases 
of this feature work.  That's it.  It doesn't hurt or help other AA issues 
in a significant way.
Apr 10 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/10/15 8:45 PM, Daniel Murphy wrote:

 "Andrei Alexandrescu"  wrote in message
 news:mg94od$1v4g$1 digitalmars.com...


 Can you make a salient argument that this is a step in the right
 direction? In that case what's the vision for future steps? Thanks! --
 Andrei


 This approach makes the common cases of AAs in the data segment work.
 This enables a very useful idiom of defining a constant lookup table and
 using it at runtime to map values.

 The hashing and AA implementations that need to be replicated in the
 compiler are trivial, and easily updated if anybody does change the
 druntime implementation.  At worst it's pretty much a copy-paste from
 the druntime sources.  And as I've said, I'm happy provide a matching
 dmd implementation of anybody's new druntime implementation.

 A future library AA implementation would not be complicated by this
 patch, because the code in this patch is only reached when an AA literal
 survives until codegen.  A library AA would lower the AA literal to some
 other construct before codegen.

 This is a step in the right direction because it will make the common
 cases of this feature work.  That's it.  It doesn't hurt or help other
 AA issues in a significant way.


This is nice work, but sorry it is hardly conductive to warm fuzzy 
feelings. -- Andrei
Apr 11 2015
parent "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Andrei Alexandrescu"  wrote in message 
news:mgcqml$2e67$1 digitalmars.com...


 This is nice work, but sorry it is hardly conductive to warm fuzzy 
 feelings. -- Andrei


It's not ideal, just better than what we have now.
Apr 11 2015
prev sibling parent "Martin Nowak" <code dawg.eu> writes:
On Friday, 10 April 2015 at 13:44:27 UTC, Daniel Murphy wrote:

 Who wouldn't?  But realistically, how many more years until 
 that happens?


I'll better change it right now, have been cooking up some stuff.
Apr 10 2015
prev sibling parent "Gary Willoughby" <dev nomad.so> writes:
On Friday, 10 April 2015 at 13:17:48 UTC, Steven Schveighoffer 
wrote:

 I'd rather see the compiler treat AA as fully library type, and 
 be able to build AA at compile time because the code is sane.


I think that was the gist of this conversation:
http://forum.dlang.org/thread/mg13tc$2ptk$1 digitalmars.com
Apr 10 2015
prev sibling next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Fri, Apr 10, 2015 at 05:54:47PM +1000, Daniel Murphy via Digitalmars-d wrote:

 One long-standing issue with AAs has been that you can't generate
 constant ones at compile time and access them at run-time.
 Workarounds are available, like initializing them in static this or
 using horribly inefficient enum AAs.


Didn't somebody submit some PRs for factoring out AA literal
initializations? Whatever happened with that? In theory, that should
have been the first step in allowing compile-time initialized AAs.


[...]

 It only works with integral types of at most 32-bits at the moment,
 but most built-in types are fairly easy to support.  The downside is
 requires re-implementing druntime's AA and hashing algorithms in the
 compiler, and keeping them in sync when either changes.


I think this is unacceptable. We're trying to decouple AA's from
compiler innards, and this is going backwards and adding a huge
dependency between them again, not to mention being a maintenance
nightmare because bugs are bound to happen when the two code bases go
out of sync. It's the very problem we've been trying to fix for years.

While I am very much in favor of compile-time initialized AA's (been
wanting that for years now), I think this is not the right approach.  In
my mind, the correct approach is to factor out the AA implementation
into a library solution, and use CTFE on that library code to generate
the compile-time initialized literal.


T

-- 
"A one-question geek test. If you get the joke, you're a geek: Seen on a
California license plate on a VW Beetle: 'FEATURE'..." -- Joshua D. Wachs -
Natural Intelligence, Inc.
Apr 10 2015
parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"H. S. Teoh via Digitalmars-d"  wrote in message 
news:mailman.1417.1428680037.3111.digitalmars-d puremagic.com...


 I think this is unacceptable. We're trying to decouple AA's from
 compiler innards, and this is going backwards and adding a huge
 dependency between them again, not to mention being a maintenance
 nightmare because bugs are bound to happen when the two code bases go
 out of sync. It's the very problem we've been trying to fix for years.


That's what tests are for.


 While I am very much in favor of compile-time initialized AA's (been
 wanting that for years now), I think this is not the right approach.  In
 my mind, the correct approach is to factor out the AA implementation
 into a library solution, and use CTFE on that library code to generate
 the compile-time initialized literal.


How many years are you willing to wait for the 'correct approach'?
Apr 10 2015
parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Sat, Apr 11, 2015 at 01:48:10AM +1000, Daniel Murphy via Digitalmars-d wrote:

 "H. S. Teoh via Digitalmars-d"  wrote in message
 news:mailman.1417.1428680037.3111.digitalmars-d puremagic.com...
 

I think this is unacceptable. We're trying to decouple AA's from
compiler innards, and this is going backwards and adding a huge
dependency between them again, not to mention being a maintenance
nightmare because bugs are bound to happen when the two code bases go
out of sync. It's the very problem we've been trying to fix for
years.


 
 That's what tests are for.


The bigger problem is that this binds us even more to the current
schizophrenic split of the AA implementation between the compiler and
druntime. We've been trying to break away from that for years, and now
you're suggesting to bring us back to square one.



While I am very much in favor of compile-time initialized AA's (been
wanting that for years now), I think this is not the right approach.
In my mind, the correct approach is to factor out the AA
implementation into a library solution, and use CTFE on that library
code to generate the compile-time initialized literal.


 
 How many years are you willing to wait for the 'correct approach'?


Didn't somebody (IIRC Igor Stepanov?) submit a bunch of PRs in this
direction? I.e., precisely to factor out AA-specific interfaces in the
compiler so that everything goes through a standard API that eventually
can be swapped for proxies to a library implementation? While it's true
I haven't seen activity on this front for a while now, I was under the
impression things were moving along quite well. If we all were to get
behind this effort and push it through instead of going back to the bad
ole split-implementation approach, maybe it would have seen the light of
day already.


T

-- 
It is of the new things that men tire --- of fashions and proposals and
improvements and change. It is the old things that startle and intoxicate. It
is the old things that are young. -- G.K. Chesterton
Apr 10 2015
parent "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"H. S. Teoh via Digitalmars-d"  wrote in message 
news:mailman.1420.1428683081.3111.digitalmars-d puremagic.com...


 The bigger problem is that this binds us even more to the current
 schizophrenic split of the AA implementation between the compiler and
 druntime.


No, it doesn't.


 We've been trying to break away from that for years, and now
 you're suggesting to bring us back to square one.


No, I'm not.


 Didn't somebody (IIRC Igor Stepanov?) submit a bunch of PRs in this
 direction? I.e., precisely to factor out AA-specific interfaces in the
 compiler so that everything goes through a standard API that eventually
 can be swapped for proxies to a library implementation? While it's true
 I haven't seen activity on this front for a while now, I was under the
 impression things were moving along quite well. If we all were to get
 behind this effort and push it through instead of going back to the bad
 ole split-implementation approach, maybe it would have seen the light of
 day already.


We're not going back to anything, it's an improvement to the current 
implementation.

I'd love to be proven wrong, but what you said is not likely to happen. 
Instead people are going to say "we should do it this way!" and nothing will 
get done.  And even if it did happen, it would replace the code I'm adding, 
not conflict with it.  ie this change is a new glue layer expansion of 
AssocArrayLiteralExp, and with a library AA that expression would already be 
converted to a struct literal/class exp/etc.

The only argument I've heard against this change that actually has merit is 
that it will make it harder to change the internals of the current AA.  I'm 
happy to provide compiler versions of any new druntime AA implementations, 
it's not very difficult.
Apr 10 2015
prev sibling next sibling parent reply "Martin Nowak" <code dawg.eu> writes:
On Friday, 10 April 2015 at 07:54:44 UTC, Daniel Murphy wrote:

 It only works with integral types of at most 32-bits at the 
 moment, but most built-in types are fairly easy to support.  
 The downside is requires re-implementing druntime's AA and 
 hashing algorithms in the compiler, and keeping them in sync 
 when either changes.


It might make sense as an intermediate step. After all it's 
fairly simple and who knows how long we'll take to change the AA 
implementation.
But what I find unacceptable is a lousy intermediate solution 
that supports int, but not short and only if the value isn't a 
const string or a class starting with the letter K.
I don't want to add another facet to the already long AA story.
So if you can fix the problem and are willing to do the work, go 
on. Just adding a tiny hack makes the situation worse IMO.
Apr 10 2015
parent "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Martin Nowak"  wrote in message 
news:apzvykkdevzgmqbsldke forum.dlang.org...


 It might make sense as an intermediate step. After all it's fairly simple 
 and who knows how long we'll take to change the AA implementation.
 But what I find unacceptable is a lousy intermediate solution that 
 supports int, but not short and only if the value isn't a const string or 
 a class starting with the letter K.
 I don't want to add another facet to the already long AA story.
 So if you can fix the problem and are willing to do the work, go on. Just 
 adding a tiny hack makes the situation worse IMO.


Oh, I agree.  The current PR is just an example, although it supports a lot 
more than just int as keys.

Current support is int,uint,short,ushort,byte,ubyte,char,wchar,dchar as 
keys, anything that can be used to initialize a global as a value.  At the 
very least it will support all integral basic types and arrays of integral 
types.  (which includes strings)
Apr 10 2015
prev sibling parent reply Martin Nowak <code+news.digitalmars dawg.eu> writes:
On 04/10/2015 09:54 AM, Daniel Murphy wrote:

 
 Is anybody else interested in seeing this in the next release?


Give me at least a few days. I have a new idea how to make that library
AA happen. Might be able to implement that over the weekend.
Apr 10 2015
next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Saturday, 11 April 2015 at 00:22:43 UTC, Martin Nowak wrote:

 On 04/10/2015 09:54 AM, Daniel Murphy wrote:

 
 Is anybody else interested in seeing this in the next release?


 Give me at least a few days. I have a new idea how to make that 
 library
 AA happen. Might be able to implement that over the weekend.


That would really be awesome !
Apr 10 2015
prev sibling parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 4/10/15 8:22 PM, Martin Nowak wrote:

 On 04/10/2015 09:54 AM, Daniel Murphy wrote:

 Is anybody else interested in seeing this in the next release?


 Give me at least a few days. I have a new idea how to make that library
 AA happen. Might be able to implement that over the weekend.


I'll await your idea, if not, I'll take a stab at it. Let me know if you 
need help. This needs to get solved.

I hope it works!

-Steve
Apr 10 2015