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.
