2013/5/27 Jonathan M Davis <[email protected]> > 1. You can't do UFCS with overloaded operators, and opEquals and opCmp are > overloaded operators. In general, I think that it would be bad to be able > to > overload operators via UFCS (especially with functions that are as core as > opEquals and opCmp), but if we could at least make it so that the compiler > allowed it in this case until the deprecation process has been completed, > then > these functions could be UFCS-able. >
Class objects and '==' (equality operation) is already treated specially. Even if a class object has opEquals method (currently Object class has opEquals, so it's always true), equality operation c1 == c2 is always forwarded to object.opEquals(c1, c2). As well we can also forward comparison operator to object.opCmp specially. > 2. super doesn't work with UFCS. Take this code for example > As Lionello already mentioned, this is not an issue. 3. The override keyword makes it so that making those functions free > functions > will break all code everywhere that uses them. override is fantastic for > catching changes in class hierarchies so that you can fix your code when > base > classes change, but it does not give us a good deprecation path. So, if we > were to make these functions free functions, the compiler would have to be > adjusted so that in this particular case, it gave a message about it (and > not > a warning, as that would cause code to break with -w) rather than giving an > error. I do think that this _should_ give an error normally, as you'd no > longer be overriding anything, but we need to be able to not make it an > error > in this case if we want a smooth transition. override is intended for > catching > bugs quite loudly and not for smooth deprecation paths. > In this case, compiler should stop reporting "does not override any function" error. If -w switch is on, the redundant override keyword usage would be warned. Kenji Hara
