http://d.puremagic.com/issues/show_bug.cgi?id=7753
Summary: Support opIndexCreate as part of index operator
overloading in user-defined types
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: hst...@quickfur.ath.cx
--- Comment #0 from hst...@quickfur.ath.cx 2012-03-22 21:18:10 PDT ---
Currently, a nested indexing expression such as:
a[b][c][d] = 0;
for a user-defined type that overloads opIndex* gets translated into:
a.opIndex(b).opIndex(c).opIndexAssign(0,d);
However, if a[b][c] do not yet exist, this will fail. This works correctly for
built-in associative arrays, because the expressions get translated into a
series of calls to _aaGetX(), which creates new entries if they don't already
exist. But currently, there is no way for a user-defined type to accomplish the
same thing.
Suggested fix: if the expression as a whole is being assigned to with an
assignment operator, then the upper-level indexing calls should be translated
into opIndexCreate() instead of just opIndex():
a[b][c][d] = 0;
becomes:
a.opIndexCreate(b).opIndexCreate(c).opIndexAssign(0,d);
If opIndexCreate is not defined, then replace it with opIndex (for backward
compatibility). The semantics of opIndexCreate(k) is to return the entry
indexed by k if it exists, and if it doesn't, create a new entry with key k and
the .init value of the value type, and return the new entry.
Preferably, this will apply to any expression that ends with a call to
opIndexAssign, opIndexUnary, and opIndexOpAssign. But at the very least, this
needs to work when the expression ends with opIndexAssign.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
