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.

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.

On Monday, May 20, 2013 17:15:32 John Colvin wrote:
> 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.

Why would this be useful? I think that it's just begging for trouble to be able to add stuff like "foo" + "bar" to the language via free functions. We don't _want_ that to be legal. That's why we have ~ in the first place. If you need to do something that you want to work with built-in types, and their operators don't do what you want, then just use a normal function rather than an operator. If you can't model your overloaded operator after what an operator does for the built-in types, it's arguably a bad choice to use an overloaded operator for that in the first place.

- Jonathan M Davis

On 05/20/2013 07:19 PM, Jonathan M Davis wrote:
> On Monday, May 20, 2013 17:15:32 John Colvin wrote:
>> 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.
>
> Why would this be useful? I think that it's just begging for trouble to be
> able to add stuff like "foo" + "bar" to the language via free functions. We
> don't _want_ that to be legal. That's why we have ~ in the first place. If you
> need to do something that you want to work with built-in types, and their
> operators don't do what you want, then just use a normal function rather than
> an operator. If you can't model your overloaded operator after what an
> operator does for the built-in types, it's arguably a bad choice to use an
> overloaded operator for that in the first place.
>
> - Jonathan M Davis
>

He just wants to be able to write:

assert(2.opBinary!"+"(3) == 5);

Which is entirely reasonable. This could be fixed by adding the corresponding built-in member function templates to the primitive types.
(Note that this would also disallow adding eg. "foo" + "bar" even when the UFCS/op-overload incompatibility is fixed.)

On 05/20/2013 05:15 PM, 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.
>

Agreed. DMD arbitrarily refuses a combination of language features. I think it is a compiler bug.

> Also, would it be a good idea to have free functions of all the
> operators (opOpAssign etc...) for builtin types somewhere?

I think built-in members are a better choice than free functions, as the operators are built-in. (Also, note that operator overloading is implemented in DMD in such a way that it is incompatible with UFCS, which does not match the language specification either).

> It's occasionally useful in generic wrappers.

Yes. Maybe you could file a bug report against the opDispatch part and an enhancement request for the built-in members part.

http://d.puremagic.com/issues/

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.

> 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.

And this is pushing UFCS beyond its purpose for the sake of temporal convenience at the expense of language.

On 05/20/2013 09:26 PM, 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.
>

This statement is wrong. As a counterexample, consider the following code:

struct S{
    void opDispatch(string s)()if(s=="foo"){ }
}

Also, I'd claim that there is no way of constructing an example where the change leads to actual problems. (It is always possible to manually remove the syntax sugar to get an equivalent program without operator overloading.)

The current situation where there exist types for which a.opBinary!"+"(b) is valid but not a+b is confusing at best.

>> 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.
>
> And this is pushing UFCS beyond its purpose for the sake of temporal
> convenience at the expense of language.

He was assuming, based on the language spec I suppose, that UFCS is compatible with operator overloading. His use case is orthogonal to that issue.

On Monday, 20 May 2013 at 19:48:48 UTC, Timon Gehr wrote:
> On 05/20/2013 09:26 PM, Maxim Fomin wrote:
>> This would also leads to bugs when invalid code is silently accepted in
>> each user-defined type where opDispatch is defined.
>>
>
> This statement is wrong. As a counterexample, consider the following code:
>
> struct S{
>     void opDispatch(string s)()if(s=="foo"){ }
> }
>
> Also, I'd claim that there is no way of constructing an example where the change leads to actual problems. (It is always possible to manually remove the syntax sugar to get an equivalent program without operator overloading.)
>
> The current situation where there exist types for which a.opBinary!"+"(b) is valid but not a+b is confusing at best.
>

I refer to more complex cases where fear introduction of subtle bugs caused by combination of buggy implementation and unintended consequences which would be revealed as unexpected behavior change of existing features. In some notorious cases such artificiality created problems (for local convenience at the expense of language consistency) are not easy to fix (ref), or are unfixable by design (@disable), or are broken and dumped without touch for ages (delegates).

Clearly, bugs should not stop from implementing a good feature, but here I see low benefits and some problems.

>>> 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.
>>
>> And this is pushing UFCS beyond its purpose for the sake of temporal
>> convenience at the expense of language.
>
> He was assuming, based on the language spec I suppose, that UFCS is compatible with operator overloading. His use case is orthogonal to that issue.

Yes, it is separate story.

On 05/20/2013 10:08 PM, Maxim Fomin wrote:
> On Monday, 20 May 2013 at 19:48:48 UTC, Timon Gehr wrote:
>> On 05/20/2013 09:26 PM, Maxim Fomin wrote:
>>> This would also leads to bugs when invalid code is silently accepted in
>>> each user-defined type where opDispatch is defined.
>>>
>>
>> This statement is wrong. As a counterexample, consider the following
>> code:
>>
>> struct S{
>>     void opDispatch(string s)()if(s=="foo"){ }
>> }
>>
>> Also, I'd claim that there is no way of constructing an example where
>> the change leads to actual problems. (It is always possible to
>> manually remove the syntax sugar to get an equivalent program without
>> operator overloading.)
>>
>> The current situation where there exist types for which
>> a.opBinary!"+"(b) is valid but not a+b is confusing at best.
>>
>
> I refer to more complex cases where fear introduction of subtle bugs
> caused by combination of buggy implementation and unintended
> consequences which would be revealed as unexpected behavior change of
> existing features.

Are you saying that the compiler is not worth fixing?

> 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?

> 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.

On Monday, 20 May 2013 at 23:10:48 UTC, Timon Gehr wrote:
> On 05/20/2013 10:08 PM, Maxim Fomin wrote:
>> I refer to more complex cases where fear introduction of subtle bugs
>> caused by combination of buggy implementation and unintended
>> consequences which would be revealed as unexpected behavior change of
>> existing features.
>
> Are you saying that the compiler is not worth fixing?

In the bottom of the comment I answered to this.

>> 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.

>> 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. 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
(including several stages of rewrite for operator overloading).
Please stop presenting a POV as absolute truth.

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.