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

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

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.

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.

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.

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 !

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

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

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

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