anonymous static array

[H. S. Teoh]

On Wed, Mar 21, 2012 at 04:15:18PM +0100, bearophile wrote:
> Jesse Phillips:
> 
> >    int[100][string] counts;
> >    int[100] a;
> >    counts["some_key"] = a;
> >    counts["some_key"][20]++;
> 
> Someone is currently trying to improve/fix AAs, this seems a
> problem that is worth trying removing.
[...]

That would be me. :-)

This is an interesting, and very important, issue. Currently, the
language translates counts["some_key"][20] into:

	counts.opIndex("some_key").opIndexUnary!"++"(20)

The problem is that the first opIndex throws a RangeError if "some_key"
doesn't exist in the AA. This makes sense (in a way) because if you
write something like

	auto x = counts["some_key"];

which translates to:

	auto x = counts.opIndex("some_key");

and "some_key" doesn't exist, then it *should* throw. But if you're
chaining the call in order to perform an operation on it, then it
shouldn't throw, but instead it should behave like opIndexAssign.

So really, if you have a chain of indexing operations like this:

	a[b][c][d]++

then the final ++ should cause the entire series of opIndex operations
to be translated differently. Perhaps there should be an opIndexCreate
which is like opIndex except that if the entry is not found it gets
created with the default value. So the above should translate to:

	a.opIndexCreate(b).opIndexCreate(c).opIndexUnary!"++"(d)

Indeed, any operation at all, not just ++, should cause the chain of
lookups to switch to opIndexCreate() instead of opIndex, for example:

	a[b][c][d] = 1

should become:

	a.opIndexCreate(b).opIndexCreate(c).opIndexAssign(1,d)


T

-- 
Today's society is one of specialization: as you grow, you learn more
and more about less and less. Eventually, you know everything about
nothing.