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.
