Optimizing Java using D

[bearophile via Digitalmars-d]

Brad Anderson:

> He and Dicebot documented the issues he came up against pretty
> thoroughly here:
>
> http://wiki.dlang.org/AA_Implementation_Issues

This looks like a bad idea, int[] != ubyte[]:

string[int[]] intAA;
ubyte[] key = [1,2,3];
intAA[key] = "abc";     // implicit convert ubyte[] -> int[] via 
.idup
auto ptr2 = key in intAA; // no .idup, but compatible comparison 
of ubyte[] with int[]


I think switching away from the built-in AAs will surely break 
some D code. So the most important job is to define a good 
future-proof API for the new AAs. Then we can accept the first 
version of the AAs to be less flexible than the current AAs. 
Later some flexibility could be restored.

In theory a compiler switch could allow D users for two compiler 
releases to switch from the new to the legacy version of AAs, but 
looking at the complexity of this change I am not sure that's 
possible and a good idea.

Bye,
bearophile