On Fri, Sep 23, 2016 at 06:33:52PM +0000, Martin Nowak via Digitalmars-d wrote:
> On Friday, 23 September 2016 at 15:17:26 UTC, jmh530 wrote:
> > On Friday, 23 September 2016 at 07:39:01 UTC, Martin Nowak wrote: Is there any benefit to adding new operator overloading to handle this case, like a opValueAssign instead of opIndexAssign ?
> 
> Maybe, making the two implementations behave identical can be done from both sides, i.e. we'll definitely make literals work for UDTs at some point, and given how widespread aa[key1][key2]++ is used we might want to come up with a UDT solution as well, but we can discuss this as a detail when we're at it.

FYI, this is related to this issue:

	https://issues.dlang.org/show_bug.cgi?id=7753


T

-- 
Valentine's Day: an occasion for florists to reach into the wallets of nominal lovers in dire need of being reminded to profess their hypothetical love for their long-forgotten.

On 09/23/2016 03:39 AM, Martin Nowak wrote:
> On Sunday, 24 May 2015 at 14:13:26 UTC, Martin Nowak wrote:
>> Would be interesting to get some opinions on this.
>>
>> https://github.com/D-Programming-Language/druntime/pull/1282
>
> Bringing up this topic again b/c there was still almost no feedback on
> the actual plan. Here is a summary.
>
> - built-in AA is too magic to be replaced by library AA
> - provide a general purpose library AA with enough benefits for people
> to live with incompatibilities
> - add a cheap toBuiltinAA adapter for compatibility of the library AA
> with existing code
> - make array and AA literals usable with UDTs
> - slowly deprecated magic behavior of the built-in AA
> - switch built-in AA to library AA
>
> Also we should plan for a std.container.aa to deal w/ all the fancy
> generic/specialized stuff.

Seems a good plan to me. I predict the difficult part will be to do that slow deprecation thing; there are quite a few subtleties. But I'm sure we'll overcome them. Thanks! -- Andrei