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
