On Tue, Dec 1, 2009 at 3:01 PM, Steven Schveighoffer <schvei...@yahoo.com> wrote: >> How about this: given only a catch-all opDispatch which implements >> dynamic dispatch, the compiler cannot statically determine if >> operators are really implemented or not. > > Why does it have to? > proposed implementation: > > compiler sees 'a + b' > compiler rewrites 'a.opBinary!"+"(b)' > does it compile? If yes, then a implements the operator. > > With opDispatch: > > compiler sees 'a + b' > compiler rewrites 'a.opDispatch!"+"(b)' > does it compile? If yes, then a implements the operator. > > I don't see the problem. > >> Since the list of operators >> is always finite, it makes sense to have them in a separate >> "namespace" of sorts. That way if you implement a catch-all >> opBinary, you're only saying that you implement all /operators/ not >> all possible methods. And vice versa, you can specify that you only >> implement some operators, but still have dynamic dispatch that >> forwards all named methods. > > opDispatch(string s, T)(T arg) if(isOperator(s)) > > opDispatch(string s, T...)(T arg) if(isSymbol(s))
Good counterpoints to my argument. So I give up on that line. Here's another, how do you implement the opBinary_r operators with opDispatch? --bb
