Member access of __gshared global object

[Puming via Digitalmars-d-learn]

Indeed it's confusing.

So AA is a value type that behaves like a pointer/reference.

We can add a rule to the initialization to make AA behave more 
like reference types:

If someone `refer` to an unitialized AA, that is, by doing:

```d
string[string] aa;

string[string] bb = aa; // bb `refers` to aa, by actually copying 
the AA struct.
```

They must want to use bb the same as aa, and it mostly will be 
followed by an assignment to bb (otherwise why bother refering 
it?). So we can initialize the AA BEFORE copying the struct, 
similar to the process before assigning an unitialized AA.

Actually, I think ANY structs that mimics a reference behavior 
should add this rule to really look like a reference.


On Thursday, 7 August 2014 at 02:17:19 UTC, H. S. Teoh via 
Digitalmars-d-learn wrote:
> On Thu, Aug 07, 2014 at 02:00:27AM +0000, Puming via 
> Digitalmars-d-learn wrote:
>> On Wednesday, 6 August 2014 at 15:42:05 UTC, Marc Schütz wrote:
> [...]
>> >Indeed, it was just what the OP suspected as the culprit.
>> 
>> You are right, I didn't know about the AA initialization 
>> problem then.
>> 
>> When I writln the AA and it outputs '[]', I thought it was
>> initialized, which in that case was actually null.
> [...]
>
> This is a known gotcha with AA's and built-in arrays: they are 
> null
> until you insert something into them, which means that while 
> they are
> null, passing them into functions that add stuff to them won't 
> update
> the original references because there is no common object that 
> null
> points to. But once they become non-empty, passing them around 
> to
> functions that change their contents will affect what's seen 
> through the
> original references, since now they are pointing at a common 
> object in
> memory.  So they behave like value types when null, but acquire
> reference semantics once they are non-empty. This can be rather
> confusing for newbies.
>
>
> T