11/14/2012 9:44 PM, Andrei Alexandrescu пишет:
On 11/14/12 1:25 AM, Don Clugston wrote:
On 12/11/12 20:42, Jonathan M Davis wrote:
On Monday, November 12, 2012 11:36:38 H. S. Teoh wrote:
I contend that the problem with built-in AA's is their implementation,
not the fact that they're built-in.
Oh, I agree, but we, as a group, have obviously failed to handle the
implementation of the built-in AAs properly, and I think that the
indications
are definitely that it's harder to get the built-in AAs right that it
would be
to create a library solution.
I disagree with that 100%.
Built-in AAs in D1 work fine (They could use a lot of improvement, but
there's nothing wrong with the basic approach, it's quite simple). It
was the idea that they could be seamlessly moved to a library type that
was an unmitigated disaster.
And for some reason, there has been a refusal to roll it back to the old
method which worked.
I think it is an absolute must that we move forward with a library
implementation.
The thing that really really should change is the bizarre 'magic null'
semantics of AAs.
This is new! What does this mean?
I'm sure it is nothing new. Basically AA is a reference type but it is
auto-magically created on the first insertion. This is called magic null
behavior.
void foo(int[int] aa){
//aa here is null
aa[1] = 1;
//now the local aa points to a new hash-map
}
void main(){
int[int] map;
foo(map);
//map in this scope is still null
assert(1 in map); // fails
}
I'm in favor of implicitly allocating an AA on definition that'll make
it a proper reference type.
--
Dmitry Olshansky
