Revised RFC on range design for D2
Andrei Alexandrescu
SeeWebsiteForEmail at erdani.org
Fri Oct 3 18:14:55 PDT 2008
Charles Hixson wrote:
> KennyTM~ wrote:
>> Sergey Gromov 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)?
>>
>> 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() )
> But if the requirement is that it should have the same *meaning* as
> a.opIndexAssign(b, a.opIndex(b) + c) , then actual implementation for
> performance can be considered a compiler optimization feature.
>
> Just because one piece of code means the same thing as another doesn't
> mean it has to be implemented the same way, or can't be optimized.
That's a good point. Compiler magic can make sure stuff like that gets
optimized, but user-defined object cannot benefit of such equivalence.
Andrei
More information about the Digitalmars-d-announce
mailing list