opDispatch and operator overloads

[Maxim Fomin]

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.