On Monday, 20 May 2013 at 19:26:28 UTC, Maxim Fomin wrote:
> On Monday, 20 May 2013 at 15:15:33 UTC, John Colvin wrote:
>> struct S {
>> 	auto opDispatch(string s)(A i){}
>> }
>>
>> struct A {}
>>
>> void main() {
>> 	S s;
>> 	A a;
>> 	s + a; //Error: incompatible types for ((s) + (a)): 'S' and 'A'
>> }
>>
>> It would be really nice if opDispatch could catch missing operator overloads.
>
> This would also leads to bugs when invalid code is silently accepted in each user-defined type where opDispatch is defined.

Could you please expand on why / give an example?

Seeing as all operators (only on user defined types, sadly) can be rewritten as op***** member functions, I don't see why having opDispatch catch missing operators is any different from it catching missing member function calls, as it currently does.

On Mon, 20 May 2013 11:15:32 -0400, John Colvin <john.loughran.colvin@gmail.com> wrote:

> struct S {
> 	auto opDispatch(string s)(A i){}
> }
>
> struct A {}
>
> void main() {
> 	S s;
> 	A a;
> 	s + a; //Error: incompatible types for ((s) + (a)): 'S' and 'A'
> }
>
> It would be really nice if opDispatch could catch missing operator overloads.

Not sure this can work.  opDispatch takes a string identifying the function name, but opBinary is a template that ALSO needs a string.

I suppose the string parameter to opDispatch could be the explicit instantiation:

s.opDispatch!"opBinary!\"+\""(a)

but that would seem extremely difficult to handle, you'd kind of need a parser to deal with it.

what is the problem with just defining opBinary to catch missing operator overloads?

> Also, would it be a good idea to have free functions of all the operators (opOpAssign etc...) for builtin types somewhere? It's occasionally useful in generic wrappers.

The name of operator overloads are the actual operators.  The opOpAssign, etc, are hooks.  Use the actual operators in generic code.  A use case to discuss may be more helpful.

-Steve

On Tuesday, 21 May 2013 at 10:53:04 UTC, Timon Gehr wrote:
> On 05/21/2013 10:40 AM, Maxim Fomin wrote:
>> On Monday, 20 May 2013 at 23:10:48 UTC, Timon Gehr wrote:
>>> ...
>>>> In some notorious cases such artificiality created
>>>> problems (for local convenience at the expense of language consistency)
>>>
>>> I don't see how this is relevant. The compiler behaviour is at the
>>> expense of language consistency, as I have argued above.
>>>
>>>> are not easy to fix (ref), or are unfixable by design (@disable), or are
>>>> broken and dumped without touch for ages (delegates).
>>>>
>>>
>>> I disagree with those assertions.
>>> What is the conceived issue with delegates?
>>
>> Conceived issue is that they are holes in type system (unlike
>> casts and unions they are not supposed to be), let alone there
>> numerous bugs related to their implementation. See Bugzilla for
>> particular examples.
>>
>
> I see. I reported a few of those recently. Some of them got fixed.
>
>>>> Clearly, bugs should not stop from implementing a good feature, but here
>>>> I see low benefits and some problems.
>>>> ...
>>>
>>> This is not about implementing a new feature. This is about fixing an
>>> implementation bug. Otherwise the compiler behaviour would need to be
>>> carried over to the spec. Doing nothing about it is not valid.
>>
>> You *think* that it is a bug and this cliam is not necessaruly
>> true.
>
> A compiler bug is a discrepancy between spec and compiler. It is a bug given the current spec.
>
>> According to spec you are promised to have a.foo(b) from
>> foo(a,b) but you are not promissed to have anything beyond that
>
> The fundamental problem is obviously that the "spec" is not fully unambiguous, but consider:
>
> https://en.wikipedia.org/wiki/Abstract_rewriting_system
>
> You are free to disagree by using different than usual fundamental notions, but if those are to be used by the language, they need to be defined by the spec.
>
> E.g. we'd need to introduce hidden state into the AST: Rewritten code would not be D code anymore, which removes most of the benefits of using rewrite rules for specification in the first place. (but given that the rewriting system given by the various rules from the spec does not appear to be confluent, this is a moot point anyway.)
>
>> (including several stages of rewrite for operator overloading).
>
> Given the assumption that the spec implies a limit on the number of such "stages", why would the limit be 1 and not 2 or 3? Why not even other numbers?
>
>> Please stop presenting a POV as absolute truth.
>
> Mathematical truth. To disagree with it you'd either:
>
> [1] Question the axioms or definitions.
>  => In this case, my argument is valid, but this is not relevant for
>  => you. I guess most of the arguing about language features goes on in
>  => this section. To settle disputes here, concrete examples showing
>  => the merits of your own viewpoint are usually useful.
>
> [2] Show a flaw in reasoning.
>
> [3] Be wrong.

According to the spec (overload page and TDPL) operators are rewritten specifically named *member* functions and calling *member* function is not the same thing as syntax to call free functions like member functions due to:
- non-member (UFCS) functions cannot be virtualized and overridden
- they do not appear in get members traits
- they cannot access all fields in general.

Using your rewriting notation operator overloading is defined as (a - expression, b - some member function other than opDispatch, c - opDispatch): if (a && b) then a->b else error. Opdispatch is defined as: if(!b && c) then b->c else error.

So, compiler works according to the spec.

By the way, your logic for a->b->c leads to following flaw:

class A
{
   void opSlice(){}
   void opDispatch(){}
}
..
a[] // unconditionally calls opDispatch since '[]'->'opSlice'->'opDispatch'

On Monday, 20 May 2013 at 19:26:28 UTC, Maxim Fomin wrote:
> And this is pushing UFCS beyond its purpose for the sake of temporal convenience at the expense of language.

I suspect you're correct on this. The only reason I suggested using UFCS was that it could be a library solution as opposed to a language/compiler modification.

On 05/21/2013 05:31 PM, Steven Schveighoffer wrote:
> On Mon, 20 May 2013 11:15:32 -0400, John Colvin
> <john.loughran.colvin@gmail.com> wrote:
>
>> struct S {
>>     auto opDispatch(string s)(A i){}
>> }
>>
>> struct A {}
>>
>> void main() {
>>     S s;
>>     A a;
>>     s + a; //Error: incompatible types for ((s) + (a)): 'S' and 'A'
>> }
>>
>> It would be really nice if opDispatch could catch missing operator
>> overloads.
>
> Not sure this can work.  opDispatch takes a string identifying the
> function name, but opBinary is a template that ALSO needs a string.
>
> I suppose the string parameter to opDispatch could be the explicit
> instantiation:
>
> s.opDispatch!"opBinary!\"+\""(a)
>

It is parsed in a different way as is assumed here, the AST after opDispatch rewrite looks like this:

(s.opDispatch!"opBinary")!"+"(a);

(which is a parse error with DMD due to a parser bug. It assumes this is a C-style cast and bails out. The internal AST representation allows this just fine though.)

> but that would seem extremely difficult to handle, you'd kind of need a
> parser to deal with it.
>

This handles your case using opDispatch:

import std.stdio,std.conv,std.algorithm,std.array;

string commaSep(T...)(T args){
    string r="";
    foreach(a;args) r~=a.to!string~",";
    return r[0..$-!!$];
}

struct S{
    template opDispatch(string name){
        template opDispatch(T...){
            auto opDispatch(S...)(S args){

writeln(this,".",name,"!"~T.stringof~"(",commaSep(args),")");
            }
        }
    }
}

void main(){
    S s;
    s.opBinary!"+"(2); // ok
    // s.foo(); // error. should IMO be fixed.
    s.foo!()(); // ok
    s.bar!([1,2,3],int)("123"); // ok
}


> what is the problem with just defining opBinary to catch missing
> operator overloads?
>

It is more boilerplate. https://github.com/D-Programming-Language/phobos/blob/bcf7dd9bd268956754bf1a034728bef29619e858/std/typecons.d#L2654


>> Also, would it be a good idea to have free functions of all the
>> operators (opOpAssign etc...) for builtin types somewhere? It's
>> occasionally useful in generic wrappers.
>
> The name of operator overloads are the actual operators.  The
> opOpAssign, etc, are hooks.  Use the actual operators in generic code.
> A use case to discuss may be more helpful.
>

Eg. use a single opDispatch to forward missing operations to a built-in member. The opDispatch/operator overloading limitation is not the only thing that currently prevents this from working nicely though.
(eg. opDispatch does not naturally support variable-length instantiation chains.)

On Tue, 21 May 2013 15:36:31 -0400, Timon Gehr <timon.gehr@gmx.ch> wrote:

> On 05/21/2013 05:31 PM, Steven Schveighoffer wrote:
>> On Mon, 20 May 2013 11:15:32 -0400, John Colvin
>> <john.loughran.colvin@gmail.com> wrote:
>>
>>> struct S {
>>>     auto opDispatch(string s)(A i){}
>>> }
>>>
>>> struct A {}
>>>
>>> void main() {
>>>     S s;
>>>     A a;
>>>     s + a; //Error: incompatible types for ((s) + (a)): 'S' and 'A'
>>> }
>>>
>>> It would be really nice if opDispatch could catch missing operator
>>> overloads.
>>
>> Not sure this can work.  opDispatch takes a string identifying the
>> function name, but opBinary is a template that ALSO needs a string.
>>
>> I suppose the string parameter to opDispatch could be the explicit
>> instantiation:
>>
>> s.opDispatch!"opBinary!\"+\""(a)
>>
>
> It is parsed in a different way as is assumed here, the AST after opDispatch rewrite looks like this:
>
> (s.opDispatch!"opBinary")!"+"(a);

OK, so the result of opDispatch needs to be a template, not a function.  OK, I can follow that

>> but that would seem extremely difficult to handle, you'd kind of need a
>> parser to deal with it.
>>
>
> This handles your case using opDispatch:
>
> import std.stdio,std.conv,std.algorithm,std.array;
>
> string commaSep(T...)(T args){
>      string r="";
>      foreach(a;args) r~=a.to!string~",";
>      return r[0..$-!!$];
> }
>
> struct S{
>      template opDispatch(string name){
>          template opDispatch(T...){
>              auto opDispatch(S...)(S args){
>  writeln(this,".",name,"!"~T.stringof~"(",commaSep(args),")");
>              }
>          }
>      }
> }
>
> void main(){
>      S s;
>      s.opBinary!"+"(2); // ok
>      // s.foo(); // error. should IMO be fixed.
>      s.foo!()(); // ok
>      s.bar!([1,2,3],int)("123"); // ok
> }
>
>
>> what is the problem with just defining opBinary to catch missing
>> operator overloads?
>>
>
> It is more boilerplate. https://github.com/D-Programming-Language/phobos/blob/bcf7dd9bd268956754bf1a034728bef29619e858/std/typecons.d#L2654

This pretty much makes my point.  I have no idea what your 3-level opDispatch does.  The proxy type, while verbose, I can understand.

Yes, lots of boilerplate.  If anything, though, that's an argument to fix how operator overloading works.

At the end of the day, it's going to be less boilerplate for the std.typecons.Proxy that one has to mixin.  User code will look the same.

-Steve

On 05/21/2013 08:24 PM, Maxim Fomin wrote:
> ...
>
> According to the spec (overload page and TDPL) operators are rewritten
> specifically named *member* functions and calling *member* function is
> not the same thing as syntax to call free functions like member
> functions due to:
> - non-member (UFCS) functions cannot be virtualized and overridden
> - they do not appear in get members traits
> - they cannot access all fields in general.
>

This is not too relevant for the current discussion since we are discussing operator overloading using opDispatch, which can be a member function.

> Using your rewriting notation

Not really.

> operator overloading is defined as (a -
> expression, b - some member function other than opDispatch, c -
> opDispatch): if (a && b) then a->b else error. Opdispatch is defined as:
> if(!b && c) then b->c else error.
>

I guess I understand what you mean, but you are missing the specification of Eg. the opSlice rewrite which would render the discussion meaningful.

Also, the language spec does not suggest a differentiation as is present in those rules between a and b.

> So, compiler works according to the spec.
>
> By the way, your logic for a->b->c leads to following flaw:
>
> class A
> {
>     void opSlice(){}
>     void opDispatch(){}
> }
> ..
> a[] // unconditionally calls opDispatch since '[]'->'opSlice'->'opDispatch'

Using your notation, if you assume there is both a rewrite '[]'->'opSlice' and 'opSlice'->'opDispatch' then yes.

The assumption of existence of a rewrite 'opSlice'->'opDispatch' is what introduces the flaw.

The spec correctly states that there is no 'opSlice'->'opDispatch' rewrite in this case, as it can be resolved otherwise.

On 05/21/2013 09:53 PM, Steven Schveighoffer wrote:
> On Tue, 21 May 2013 15:36:31 -0400, Timon Gehr <timon.gehr@gmx.ch> wrote:
>
>> On 05/21/2013 05:31 PM, Steven Schveighoffer wrote:
>>> ...
>>>
>>
>> This handles your case using opDispatch:
>>
>> import std.stdio,std.conv,std.algorithm,std.array;
>>
>> string commaSep(T...)(T args){
>>      string r="";
>>      foreach(a;args) r~=a.to!string~",";
>>      return r[0..$-!!$];
>> }
>>
>> struct S{
>>      template opDispatch(string name){
>>          template opDispatch(T...){
>>              auto opDispatch(S...)(S args){
>>  writeln(this,".",name,"!"~T.stringof~"(",commaSep(args),")");
>>              }
>>          }
>>      }
>> }
>>
>> void main(){
>>      S s;
>>      s.opBinary!"+"(2); // ok
>>      // s.foo(); // error. should IMO be fixed.
>>      s.foo!()(); // ok
>>      s.bar!([1,2,3],int)("123"); // ok
>> }
>>
>>
>>> what is the problem with just defining opBinary to catch missing
>>> operator overloads?
>>>
>>
>> It is more boilerplate.
>> https://github.com/D-Programming-Language/phobos/blob/bcf7dd9bd268956754bf1a034728bef29619e858/std/typecons.d#L2654
>>
>
> This pretty much makes my point.  I have no idea what your 3-level
> opDispatch does.

1st level: member name
2nd level: explicit template arguments
3rd level: ifti-deduced arguments.


> The proxy type, while verbose, I can understand.
>

Fair point.

> Yes, lots of boilerplate.  If anything, though, that's an argument to
> fix how operator overloading works.
>
> At the end of the day, it's going to be less boilerplate for the
> std.typecons.Proxy that one has to mixin.  User code will look the same.
>...

For user code there is a difference eg. in how inflated the __traits(allMembers) result will be.

On Tue, 21 May 2013 16:16:08 -0400, Timon Gehr <timon.gehr@gmx.ch> wrote:

> On 05/21/2013 09:53 PM, Steven Schveighoffer wrote:

>> At the end of the day, it's going to be less boilerplate for the
>> std.typecons.Proxy that one has to mixin.  User code will look the same.
>> ...
>
> For user code there is a difference eg. in how inflated the __traits(allMembers) result will be.

I consider it a weak argument.  I wouldn't expect the __traits(allMembers) to be meaningful for a proxy type.

As you want it, it would have two members, opDispatch, and the wrapped member.  I don't know how useful that would be.  Admittedly, I don't regularly use the allMembers trait.

-Steve