A possible solution for the opIndexXxxAssign morass
Jason House
jason.james.house at gmail.com
Wed Oct 14 13:47:59 PDT 2009
Bill Baxter Wrote:
> On Wed, Oct 14, 2009 at 7:42 AM, Jason House
> <jason.james.house at gmail.com> wrote:
> > Andrei Alexandrescu Wrote:
> >
> >> Right now we're in trouble with operators: opIndex and opIndexAssign
> >> don't seem to be up to snuff because they don't catch operations like
> >>
> >> a[b] += c;
> >>
> >> with reasonable expressiveness and efficiency.
> >
> > I would hope that *= += /= and friends could all be handled efficiently with one function written by the programmer. As I see it, there are 3 basic steps:
> > 1. Look up a value by index
> > 2. Mutate the value
> > 3. Store the result
>
> And as Chad J reminds us, same goes for in-place property mutations
> like a.b += c.
> It's just a matter of accessing .b vs .opIndex(b). And really
> same goes for any function a.memfun(b) += c could benefit from the
> same thing (a.length(index)+=3 anyone?)
>
> > it's possible to use opIndex for #1 and opIndexAssign for #3, but that's not efficient. #1 and #3 should be part of the same function, but I think #2 shouldnot be. What about defining an opIndexOpOpAssign that accepts a delegate for #2 and then use compiler magic to specialize/inline it?
>
> It could also be done using a template thing to inject the "mutate the
> value" operation:
The only issue with templates is that they're never virtual
More information about the Digitalmars-d
mailing list