<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2013/5/27 Jonathan M Davis <span dir="ltr"><<a href="mailto:jmdavisProg@gmx.com" target="_blank">jmdavisProg@gmx.com</a>></span><br><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

1. You can't do UFCS with overloaded operators, and opEquals and opCmp are<br>
overloaded operators. In general, I think that it would be bad to be able to<br>
overload operators via UFCS (especially with functions that are as core as<br>
opEquals and opCmp), but if we could at least make it so that the compiler<br>
allowed it in this case until the deprecation process has been completed, then<br>
these functions could be UFCS-able.<br></blockquote><div><br></div><div>Class objects and '==' (equality operation) is already treated specially.</div><div>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.</div>

<div> </div><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">2. super doesn't work with UFCS. Take this code for example<br>

</blockquote><div><br></div><div>As Lionello already mentioned, this is not an issue. </div><div><br></div><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">


3. The override keyword makes it so that making those functions free functions<br>
will break all code everywhere that uses them. override is fantastic for<br>
catching changes in class hierarchies so that you can fix your code when base<br>
classes change, but it does not give us a good deprecation path. So, if we<br>
were to make these functions free functions, the compiler would have to be<br>
adjusted so that in this particular case, it gave a message about it (and not<br>
a warning, as that would cause code to break with -w) rather than giving an<br>
error. I do think that this _should_ give an error normally, as you'd no<br>
longer be overriding anything, but we need to be able to not make it an error<br>
in this case if we want a smooth transition. override is intended for catching<br>
bugs quite loudly and not for smooth deprecation paths.<br></blockquote><div><br></div><div>In this case, compiler should stop reporting "does not override any function" error.</div><div>If -w switch is on, the redundant override keyword usage would be warned.</div>
<div><br></div><div>Kenji Hara</div></div></div></div>