Revised RFC on range design for D2
Sergey Gromov
snake.scaly at gmail.com
Thu Oct 2 19:05:34 PDT 2008
Fri, 3 Oct 2008 09:37:46 +0900,
Bill Baxter wrote:
> On Fri, Oct 3, 2008 at 9:32 AM, Bill Baxter <wbaxter at gmail.com> wrote:
> > On Fri, Oct 3, 2008 at 8:04 AM, Sergey Gromov <snake.scaly at gmail.com> wrote:
> >> Thu, 02 Oct 2008 15:03:42 -0500,
> >> Andrei Alexandrescu wrote:
> >>> Yah, overloaded ops are due for an overhaul. I'm almost afraid to ask...
> >>> any ideas? :o)
> >>>
> >>> One goal is to fix opIndexAssign and make it work similar to the way it
> >>> works in arrays, e.g. a[b] += c. Indexing into hash tables is a good
> >>> test bed.
> >>
> >> What's wrong with a.opIndexAssign(b, a.opIndex(b) + c)?
> >>
> >
> > Indeed. I thought there wasn't a lot of debate needed on this, just action.
> .
> ... except these extras do have the same issue that plain property
> assignment does. They would open up a new class of things that are
> valid code but don't behave as expected. writefln += 5.
>
> And also, a[b] += c should probably be rewritten as "a.opIndex(b) +=
> c" *if* a returns a reference of some sort. Ok, so maybe there is a
> little to talk about. :-)
I think that any expression "a @= b" should first check whether the
expression on the left is an lvalue. If yes then use it as any other
lvalue, otherwise try to re-write an expression using op at Assign. This
works in many scenarios, like opIndex returning a reference.
More information about the Digitalmars-d-announce
mailing list