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.

Last night this idea occurred to me: we could simply use overloading with the existing operator names. Consider:

a += b

gets rewritten as

a.opAddAssign(b)

Then how about this - rewrite this:

a[b] += c

as

a.opAddAssign(b, c);

There's no chance of ambiguity because the parameter counts are different. Moreover, this scales to multiple indexes:

a[b1, b2, ..., bn] = c

gets rewritten as

a.opAddAssign(b1, b2, ..., bn, c)

What do you think? I may be missing some important cases or threats.


Andrei

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.
> 
> Last night this idea occurred to me: we could simply use overloading with the existing operator names. Consider:
> 
> a += b
> 
> gets rewritten as
> 
> a.opAddAssign(b)
> 
> Then how about this - rewrite this:
> 
> a[b] += c
> 
> as
> 
> a.opAddAssign(b, c);
> 
> There's no chance of ambiguity because the parameter counts are different. Moreover, this scales to multiple indexes:
> 
> a[b1, b2, ..., bn] = c
> 
> gets rewritten as
> 
> a.opAddAssign(b1, b2, ..., bn, c)
> 
> What do you think? I may be missing some important cases or threats.
> 
> 
> Andrei

Well timed. I just wrote this operator overloading proposal, part 1.
http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP7
I concentrated on getting the use cases established.

The indexing thing was something I didn't have a solution for.

BTW we need to deal with slices as well as indexes. I think the way to do this is to make a slice into a type of index.

On Tue, 13 Oct 2009 11:16:01 -0400, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> 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.
>
> Last night this idea occurred to me: we could simply use overloading with the existing operator names. Consider:
>
> a += b
>
> gets rewritten as
>
> a.opAddAssign(b)
>
> Then how about this - rewrite this:
>
> a[b] += c
>
> as
>
> a.opAddAssign(b, c);
>
> There's no chance of ambiguity because the parameter counts are different. Moreover, this scales to multiple indexes:
>
> a[b1, b2, ..., bn] = c
>
> gets rewritten as
>
> a.opAddAssign(b1, b2, ..., bn, c)

I'm guessing you meant opAssign here, or meant to write +=?

> What do you think? I may be missing some important cases or threats.

It's simple, and gets rid of all opIndex operators except for opIndex itself.

The question then becomes, what if you wanted to overload this?

a[b][c] += d;

You can do a[b] returns a ref.  But then you now allow a[b] op x, thereby possibly exposing a private piece of info.  This may or may not be important.

I like the way your idea is going.

-Steve

Steven Schveighoffer wrote:
> On Tue, 13 Oct 2009 11:16:01 -0400, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
>> There's no chance of ambiguity because the parameter counts are different. Moreover, this scales to multiple indexes:
>>
>> a[b1, b2, ..., bn] = c
>>
>> gets rewritten as
>>
>> a.opAddAssign(b1, b2, ..., bn, c)
> 
> I'm guessing you meant opAssign here, or meant to write +=?

Oh, sorry. I meant to write +=.

>> What do you think? I may be missing some important cases or threats.
> 
> It's simple, and gets rid of all opIndex operators except for opIndex itself.
> 
> The question then becomes, what if you wanted to overload this?
> 
> a[b][c] += d;
> 
> You can do a[b] returns a ref.  But then you now allow a[b] op x, thereby possibly exposing a private piece of info.  This may or may not be important.
> 
> I like the way your idea is going.

Great. Indeed the proposed solution leaves a[b][c] += d problematic, and also prevents this potential development:

a += b + c + d;

to be rewritten as:

a.opAddAssign(b, c, d);


Andrei

On Tue, 13 Oct 2009 19:16:01 +0400, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> 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.
>
> Last night this idea occurred to me: we could simply use overloading with the existing operator names. Consider:
>
> a += b
>
> gets rewritten as
>
> a.opAddAssign(b)
>
> Then how about this - rewrite this:
>
> a[b] += c
>
> as
>
> a.opAddAssign(b, c);
>
> There's no chance of ambiguity because the parameter counts are different. Moreover, this scales to multiple indexes:
>
> a[b1, b2, ..., bn] = c
>
> gets rewritten as
>
> a.opAddAssign(b1, b2, ..., bn, c)
>
> What do you think? I may be missing some important cases or threats.
>
>
> Andrei

How about this case:

a[b1..b2] = c;

?

I could be solved if b1..b2 would return some built-in range type, defined in object.d, though.

On Tue, 13 Oct 2009 12:28:05 -0400, Denis Koroskin <2korden@gmail.com> wrote:

> On Tue, 13 Oct 2009 19:16:01 +0400, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> 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.
>>
>> Last night this idea occurred to me: we could simply use overloading with the existing operator names. Consider:
>>
>> a += b
>>
>> gets rewritten as
>>
>> a.opAddAssign(b)
>>
>> Then how about this - rewrite this:
>>
>> a[b] += c
>>
>> as
>>
>> a.opAddAssign(b, c);
>>
>> There's no chance of ambiguity because the parameter counts are different. Moreover, this scales to multiple indexes:
>>
>> a[b1, b2, ..., bn] = c
>>
>> gets rewritten as
>>
>> a.opAddAssign(b1, b2, ..., bn, c)
>>
>> What do you think? I may be missing some important cases or threats.
>>
>>
>> Andrei
>
> How about this case:
>
> a[b1..b2] = c;
>
> ?
>
> I could be solved if b1..b2 would return some built-in range type, defined in object.d, though.

That already has an operator:
int opSliceAssign(int v, size_t x, size_t y);
a[3..4] = v;	// same as a.opSliceAssign(v,3,4);

On Tue, Oct 13, 2009 at 9:08 AM, Steven Schveighoffer <schveiguy@yahoo.com> wrote:
> On Tue, 13 Oct 2009 11:16:01 -0400, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> 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.
>>
>> Last night this idea occurred to me: we could simply use overloading with the existing operator names. Consider:
>>
>> a += b
>>
>> gets rewritten as
>>
>> a.opAddAssign(b)
>>
>> Then how about this - rewrite this:
>>
>> a[b] += c
>>
>> as
>>
>> a.opAddAssign(b, c);
>>
>> There's no chance of ambiguity because the parameter counts are different. Moreover, this scales to multiple indexes:
>>
>> a[b1, b2, ..., bn] = c
>>
>> gets rewritten as
>>
>> a.opAddAssign(b1, b2, ..., bn, c)
>
> I'm guessing you meant opAssign here, or meant to write +=?
>
>> What do you think? I may be missing some important cases or threats.
>
> It's simple, and gets rid of all opIndex operators except for opIndex itself.

Huh? It didn't sound to me like it would get rid of anything, except for the use of the word "index" in many methods that have to do with index operations.  That just seems confusing to me.   I think the opIndexXxxAssign functions may need to be added, but adding them by overloading existing names doesn't seem a win to me.

--bb

On Tue, 13 Oct 2009 12:21:20 -0400, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> Steven Schveighoffer wrote:
>> On Tue, 13 Oct 2009 11:16:01 -0400, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
>>> There's no chance of ambiguity because the parameter counts are different. Moreover, this scales to multiple indexes:
>>>
>>> a[b1, b2, ..., bn] = c
>>>
>>> gets rewritten as
>>>
>>> a.opAddAssign(b1, b2, ..., bn, c)
>>  I'm guessing you meant opAssign here, or meant to write +=?
>
> Oh, sorry. I meant to write +=.
>
>>> What do you think? I may be missing some important cases or threats.
>>  It's simple, and gets rid of all opIndex operators except for opIndex itself.
>>  The question then becomes, what if you wanted to overload this?
>>  a[b][c] += d;
>>  You can do a[b] returns a ref.  But then you now allow a[b] op x, thereby possibly exposing a private piece of info.  This may or may not be important.
>>  I like the way your idea is going.
>
> Great. Indeed the proposed solution leaves a[b][c] += d problematic, and also prevents this potential development:
>
> a += b + c + d;
>
> to be rewritten as:
>
> a.opAddAssign(b, c, d);
>
>
> Andrei

Well, that last case I'd prefer handled by something more generic, like an opExpression(Expr, T...)(T params); (i.e. a way of doing expression template/ BLADE like stuff, without the syntactic or runtime overhead.

On Tue, 13 Oct 2009 20:34:06 +0400, Robert Jacques <sandford@jhu.edu> wrote:

> On Tue, 13 Oct 2009 12:28:05 -0400, Denis Koroskin <2korden@gmail.com> wrote:
>
>> On Tue, 13 Oct 2009 19:16:01 +0400, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> 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.
>>>
>>> Last night this idea occurred to me: we could simply use overloading with the existing operator names. Consider:
>>>
>>> a += b
>>>
>>> gets rewritten as
>>>
>>> a.opAddAssign(b)
>>>
>>> Then how about this - rewrite this:
>>>
>>> a[b] += c
>>>
>>> as
>>>
>>> a.opAddAssign(b, c);
>>>
>>> There's no chance of ambiguity because the parameter counts are different. Moreover, this scales to multiple indexes:
>>>
>>> a[b1, b2, ..., bn] = c
>>>
>>> gets rewritten as
>>>
>>> a.opAddAssign(b1, b2, ..., bn, c)
>>>
>>> What do you think? I may be missing some important cases or threats.
>>>
>>>
>>> Andrei
>>
>> How about this case:
>>
>> a[b1..b2] = c;
>>
>> ?
>>
>> I could be solved if b1..b2 would return some built-in range type, defined in object.d, though.
>
> That already has an operator:
> int opSliceAssign(int v, size_t x, size_t y);
> a[3..4] = v;	// same as a.opSliceAssign(v,3,4);

I meant:

a[b1..b2] += c;

Another thing I dislike about this proposal is that "a[b] += c;" translates into "opAddAssign" and doesn't mention "index" while "a[b] = c;" does ("opIndexAssign").

On 2009-10-13 11:16:01 -0400, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> said:

> 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.
> 
> Last night this idea occurred to me: we could simply use overloading with the existing operator names. Consider:
> 
> a += b
> 
> gets rewritten as
> 
> a.opAddAssign(b)
> 
> Then how about this - rewrite this:
> 
> a[b] += c
> 
> as
> 
> a.opAddAssign(b, c);

I'd rewrite it as opIndexAddAssign(b, c); That way you can also rewrite:

	a[b..c] = d;

as

	opSliceAddAssign(b, c, d);


> There's no chance of ambiguity because the parameter counts are different. Moreover, this scales to multiple indexes:
> 
> a[b1, b2, ..., bn] = c
> 
> gets rewritten as
> 
> a.opAddAssign(b1, b2, ..., bn, c)

That looks like a good idea, although I'd be a little tempted to put the variable-length part at the end so you can easily choose to use variadic arguments.

Also noteworthy: none of this work if you want to mix index and slices:

	a[b, c..d] = f;


> What do you think? I may be missing some important cases or threats.

Wasn't the bigger problem with operator overloading the fact that you have to redefine it for every primitive operator? I seem to recall you arguing for a way to overload all the operators at the same time. Where's that going?


-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/