hashed array?

Dmitry Olshansky dmitry.olsh at gmail.com
Wed Nov 14 10:20:13 PST 2012


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


More information about the Digitalmars-d mailing list