opDispatch and operator overloads

[Timon Gehr]

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.