new AssociativeArray implementation

[IgorStepanov]

This PR is the next step to creating AA as full library type.
Next step is replacing object.AssociativeArray with this AssociativeArray.
After that we should provide our AssociativeArray all functions which have builtin AA. (There are some language changes needed).
At the end of this way we'll able to replace V[K] type with AssociativeArray!(K, V) automatically during semantic and remove most of special AA cases/hacks from compiler.

[yebblies]

I still have the same objections I raised in #668. This doesn't answer any of them. I strongly recommend rolling back the AA druntime implementation until these issues are solved.

The current state of associative arrays has been caused by half-implementing a transition to druntime. To prevent the same mistake, none of this should be merged until a 100% complete replacement has been constructed.

[IgorStepanov]

@yebblies
This PR can't answer to all your questions, because it's a part of work.
BTW, this PR doesn't conflict with your work, because it's only AA impl (rt.aaA) replacement.
Even if you'll remove object.AssociativeArray from druntime and compiler, I'll able to replace rt.aaA with this.
And I don't strongly need an object.AssociativeArray. This implementation can works without it and any other magic types.
Do you have any other objections aganist this implementation?

That's what I need to integrate this pull:

1. Add to object two functions:

void* aaLiteral(T...)(T elems);
void* aaInit(Key, Value)();

At the first stage aaLiteral will pass elems to _d_assocarrayliteralTX and aaInit will return null.
2. Make dmd patch, which replace AssocArrayLiteralExp with calling aaLiteral during semantic, and change TypeAArray::defaultInit to calling aaInit!(Key, Value)().
3. Change aaLiteral to call core.internal.associativeArrayLiteral and aaInit(Key, Value)() to return &core.internal.AssociativeArray!(Key, Value).null_impl.
Both functions will be CTFE'able.
Other operations I'll provide through _aaXXX functions transparently for compiler and your PR.
Advantages of this work:

1. Potentially high speed (Allow inlining, allow static information about type)
2. CTFE compatibility. (AA literal will be buildable at compile type.
3. Type-safe implementation
4. Way to implementing true-library associative array.

[yebblies]

I understand your plan, I just think it needs to be completely implemented and tested before any of the parts start getting merged into the compiler. I'm especially concerned with the impact this will have on ctfe, in terms of introducing regressions.

eg The signature void* aaLiteral(T...)(T elems); is not type-safe, and will need to be special cased in ctfe.

Also, will all error messages show the correct V[K] type?

[ibuclaw]

I'm in some agreement. UFCs seem like a more natural route to go down for CTFE-able AAs.

[IgorStepanov]

I'm in some agreement. UFCs seem like a more natural route to go down for CTFE-able AAs.

I don't replace AA-front side now. We can remove object.AssociativeArray, create UFCS methods and work with my implementation through this UFCS methods and _aaXXX functions.

Also, will all error messages show the correct V[K] type?

User will not see my type (in this stage), like he doesn't see rt.aaA.AA structure.

I just think it needs to be completely implemented and tested before any of the parts start getting merged into the compiler. I'm especially concerned with the impact this will have on ctfe, in terms of introducing regressions.

Yes, I've full reworked dmd part and now it passes all dmd, druntime and phobos tests with old implementation. I've replace initializer in toDt/toElem levels and ctfe doesn't see my changes.

The signature void* aaLiteral(T...)(T elems); is not type-safe

Like other AA-to-compiler interface. BTW, I don't do any casts, I do toElem and toDt for call expressions of aaInit/aaLiteral at the last stage.

[MartinNowak]

I'm having quite a lot of trouble to get this working.
Also I'd rather clean up the old implementation, e.g. getting rid of the prime table and using a pow2 growth scheme as in HashTab.

[AndrewEdwards]

@MartinNowak, What's the status on this? It is identified as a 2.066 candidate but to date has failed all auto-tests.

[AndrewEdwards]

Ping @IgorStepanov

[yebblies]

Dunno why this was milestoned.

[IgorStepanov]

@AndrewEdwards Hello. I was busy last half of year, sorry. Now, I'm fixing those patches (this PR and dmd changes) to work with new dmd/druntime (without object.AssociativeArray). I hope, I'll introduce new pack of patches at this/next week.

[AndrewEdwards]

@IgorStepanov, thanks for the swift response.

[ibuclaw]

This/next week is still too late for 2.066. :)

I still don't understand the reasoning for this when (thanks to @yebblies) AssociativeArray and all its horrible compiler bugs were removed.

[IgorStepanov]

This/next week is still too late for 2.066. :)

Yes. Anyway, big changes should't be merged shortly before release.

I still don't understand the reasoning for this when (thanks to @yebblies) AssociativeArray and all its horrible compiler bugs were removed.

The first stage is not intended to give a special status for internal.AssociativeArray. First stage is a reimplementation of runtime AA using modern D style. However, this stage will give us some advantages:

1. Creating static AA instances at compile time.
2. Use better hash algorithm.
3. Possible better performance, because new implementation uses templates instead of TypeInfo.

After that (at second stage), we can try to provide AssociativeArray behaivour, similar to D AA. This work need some discussions and language changes.
And when AssociativeArray will be work similar to AA, we will able to replace V[K] with AssociativeArray!(K, V) during semantic.
And of course, I don't want to separate AA functional between two types.

[IgorStepanov]

I've closed this. See #934