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? 

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?

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

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

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

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

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

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.
> 
> 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 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.

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

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