Revised RFC on range design for D2

Bill Baxter wbaxter at gmail.com
Fri Oct 3 12:34:46 PDT 2008


On Fri, Oct 3, 2008 at 11:43 PM, Sergey Gromov <snake.scaly at gmail.com> wrote:
> Fri, 03 Oct 2008 20:59:54 +0800,
> KennyTM~ wrote:
>> Sergey Gromov wrote:
>> > What's wrong with a.opIndexAssign(b, a.opIndex(b) + c)?
>>
>> Probably performance.
>>
>> Consider seeking to the end of a 100M-node single-linked list, and
>> increase its content by 1.
>>
>> But I agree that if something like .opIndexAddAssign() is not defined,
>> the compiler should fall back to use a.opIndexAssign(b, a.opIndex(b)+c).
>>
>> (The same idea can be extended to properties and .opSlice() )
>
> No, if you want performance in this particular case you define
>
> ref int opIndex()
>
> because I think whenever compiler encounters a[x]++ it should first test
> whether a[x] is an lvalue and if yes use it accordingly.  And only if it
> is not it should fall back to .opIndexAddButProbablyNotAssign() special
> overloads.

Yeh, but then you lose encapsulation.  That's fine for some cases,
like a vector, but in other cases it can be very handy to be able to
get a notification any time one of your values changes.  You lose that
ability once you start handing out pointers to whoever asks for one.

--bb


More information about the Digitalmars-d-announce mailing list