http://d.puremagic.com/issues/show_bug.cgi?id=7520
hst...@quickfur.ath.cx changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |hst...@quickfur.ath.cx
--- Comment #2 from hst...@quickfur.ath.cx 2013-02-28 20:12:58 PST ---
I've used opDollar in some of my code; it appears to work like this:
obj[$] gets lowered to obj.opIndex(obj.opDollar!0);
obj[1,$] gets lowered to obj.opIndex(1, obj.opDollar!1);
obj[1,2,$] gets lowered to obj.opIndex(1, 2, obj.opDollar!2);
and so on. The $ is recognized in subexpressions as well, so:
obj[1, func(2,$), 3] gets lowered to obj.opIndex(1, func(2, obj.opDollar!1),
3).
In other words, the compile-time argument of opDollar is the index of position
it appears in, in the arguments of the indexing operator.
Unfortunately, it appears that only opDollar!0 is implemented for opSlice
(besides, slicing syntax currently does not support multiple ranges).
<aside>
But even with the current opIndex and opDollar, one can hack around the lack of
multidimensional opSlice by defining a custom range type, say: struct Range {
int start,end; }, then you can overload opIndex to recognize pseudo-slicing
syntax:
obj[Range(1,2), Range(2,$)] gets translated to obj.opIndex(Range(1,2),
Range(2,obj.opDollar!1)), so you just have to define: auto opIndex(Range r1,
Range r2), and you can have pseudo-multidimensional slicing. One can even use
variadic parameters to handle a mix of slicing and indexing:
auto opIndex(R...)(R args) {
foreach (arg; args) {
static if (typeof(arg) : Range) {
// slice this dimension
} else if (typeof(arg) : indexType) {
// index this dimension
}
}
}
The $'s are correctly translated to opDollar!i based on their position i in the
[] operator, so this will correctly handle things like obj[$-1, Range(0,$-1)],
obj[Range(0,$), 10], etc..
</aside>
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
