Revised RFC on range design for D2
Steven Schveighoffer
schveiguy at yahoo.com
Fri Oct 3 13:50:01 PDT 2008
"Steven Schveighoffer" wrote
> "Andrei Alexandrescu" wrote
>> Sergey Gromov wrote:
>>> 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.
>>
>> That's a good rule, but a[b] @= c on a hash is not helped by it.
>
> I think Sergey didn't write his rules correctly. If a is an lvalue, use
> it as any other lvalue, which *includes* trying op at Assign.
>
> If a is not an lvalue, then rewrite the expression as a = a @b, without
> expanding operators, then use normal operator expansion to compile the
> statement.
>
> If neither works, then it is a syntax error.
>
> This should be valid for all cases. For example a hash that returns a
> reference for opIndex:
>
> a[b] += c;
>
> a.opIndex(b) is an lvalue, so try: a.opIndex(b).opAddAssign(c). If that
> doesn't work, then syntax error.
>
> case 2, a[b] is an rvalue:
>
> rewrite as a[b] = a[b] + c;
>
> expand operators:
>
> a.opIndexAssign(a[b] + c, b);
> a.opIndexAssign(a.opIndex(b) + c, b);
>
> An example of a failure:
>
> int foo(int x) {...}
>
> foo(5) += 6;
>
> left side is an rvalue, so try rewriting:
>
> foo(5) = foo(5) + 6;
>
> syntax error, foo(5) is still an rvalue
>
> Any cases that break with these rules?
After thinking about this some more, I don't even thing the rvalue/lvalue
check is necessary. Just try:
a.op at Assign(b);
If that doesn't compile under the current rules, try rewriting as:
a = a @ b;
If that doesn't compile under the current rules, then it's a syntax error.
-Steve
More information about the Digitalmars-d-announce
mailing list