Empty array literals

[grauzone]

Lutger wrote:
> Michael Rynn wrote:
> 
>>> That IS what Walter thinks, actually. It's being moved to libraries
>>> (which is why there have been some nasty AA regressions in the past few
>>> compiler releases :-( ).
>> Sounds good. So the  source is in druntime?
>> Does that mean I can find out how to implement opIn ?.
>>
>> I found the file druntime/src/rt/aaA.d
>>
>> The code looks nice, and its got a function _aaIn, which "Determine if
>> key is in aa".
>>
>> I want to implement opIn for my own class, but I have not found an
>> example.
>>
>> This week I have made a RadixTree implementation, for immutable array
>> keys based on char or ubyte only. Values no such restriction.
>>
>> I measured its lookups can be ~20x faster than AA equivalent.
>> Insertions somewhat slower than AA, even with a node preallocation heap
>> for speedup.
>>
>> I am sure I read about a radix tree in the past, but have not seen an
>> implementation in current libraries.  It would be nice to have one, if
>> only to stop me or others wasting time doing another. If its simple
>> enough for me to make, there should be one there already.
>>
>> I took a pretty recursive Java implementation (because I was supposed to
>> be studying java) and reworked it.
>>
>> So although AA are "in the library", there is not yet an obvious facility
>> to completely replace the AA implementation with another equivalent (or
>> even same) using non- druntime code and the facilities of struct,
>> operator overrides etc.
>>
>> Whats the magic hook that will connect D source AA type operator "in"  to
>> a class or struct function of a Tree, AA or trie?  Is there any great
>> advantage to the AA being struct rather than class based?

I suppose the compiler automatically maps AAs to this struct: 
http://dsource.org/projects/druntime/browser/trunk/import/object.di#L304

The struct simply calls the "old" runtime AA methods like in D1.

Maybe one can simply edit the object.di to plug in his own implementation.

>> I might like to upload the radix tree implementation, to see how it can
>> be improved.
>>
>> Thanks,
>> Michael R.
> 
> Perhaps this dsource project will interest you: 
> http://www.dsource.org/projects/aa

Shouldn't this measure memory usage as well?