question on [Issue 7853]

[Tobias Pankrath]

On 11/05/2012 12:43 PM, Dan wrote:
> On Monday, 5 November 2012 at 09:10:41 UTC, Tobias Pankrath wrote:


> I have not figured what to look at for associative arrays. For example,
> in .../druntime/import/object.di there is a struct called
> AssociativeArray which I imagine the [ "foo" : "goo" ] syntactic sugar
> gets me to. It has the keys property as non-const and internally it does
> a cast:
>      Key[] keys() @property
>      {
>          auto a = _aaKeys(p, Key.sizeof);
>          return *cast(Key[]*) &a;
>      }
> I'm not even sure if this is the right code to look at when dealing with
> associative arrays described in TDPL?

AA are implemented in object_.d, rt/aaA.d and in the compiler. For 
example the _aaKeys function is defined in rt/aaA.d.

I don't now any details though. You may take a look here: 
http://www.digitalmars.com/d/archives/digitalmars/D/Replacing_AA_s_in_druntime_161307.html


>>
>> The code below works, too. But to be honest, I don't now why the
>> compiler complains that the postblit is not callable in your version
>> but does not actually get called in mine.
>>
>
>  While the signature below gets called, it is futile since
> incipient instance can not be patched which is the purpose.
Yeah your are right here.
> I think
> <this(this) const> should not be allowed but this(const ref this) or
> this(const this) should be allowed and preferred.
The problem is, that you actually don't have access to the original 
struct. So it's not clear how to define the semantics of this(const this).

> I don't understand how
> the compiler ends up with the postblit message without the cast. I hope
> the lack of const on assoc array properties and foreach are oversights
> rendering the casts safe and on a future release of D rendering them
> unnecessary.

I guess so.