<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Oct 3, 2014 at 1:28 PM, Arthur O'Dwyer <span dir="ltr"><<a href="mailto:arthur.j.odwyer@gmail.com" target="_blank">arthur.j.odwyer@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Fri, Oct 3, 2014 at 12:42 PM, Richard Smith <<a href="mailto:richard@metafoo.co.uk">richard@metafoo.co.uk</a>> wrote:<br>
> On Fri, Oct 3, 2014 at 12:41 PM, Richard Smith <<a href="mailto:richard@metafoo.co.uk">richard@metafoo.co.uk</a>> wrote:<br>
>> On Fri, Oct 3, 2014 at 12:16 PM, Arthur O'Dwyer <<a href="mailto:arthur.j.odwyer@gmail.com">arthur.j.odwyer@gmail.com</a>> wrote:<br>
>>><br>
</span><span class="">>>> (Summary: I agree with Doug/Fariborz.)<br>
>>><br>
>>> IIUC, there are a whole bunch of cases to consider, due to C++'s<br>
>>> unfortunate decision to have both "virtual" and "override" be implicit<br>
>>> on member functions that the compiler can deduce are in fact virtual<br>
>>> and/or override. Forgetting about those *implicit* qualifiers for the<br>
>>> moment, we have three *explicit* cases involving "final":<br>
>>><br>
>>> (1a)    virtual int foo() override final;<br>
>>> (2a)    virtual int foo() final;           // where 'override' is not<br>
>>> implied<br>
>>> (3a)    int foo() final;                   // where 'virtual override'<br>
>>> are not implied<br>
>>><br>
>>> 1a is the expected-most-common-and-most-correct usage.<br>
>><br>
>> 1a is verbose to the point of being ridiculous, verbose,<br>
> s/, verbose,/, redundant,/ =)<br>
>> and banned by several style guides. The best way to write this is 3a,<br>
>> which means *exactly* the same thing.<br>
<br>
</span>Ha!  Wrong!  You see, even when I explicitly spelled out all the<br>
possible cases, WITH COPIOUS COMMENTS, you STILL got confused by (3a);<br>
you thought it was equivalent to (1d), simply because it happens to be<br>
spelled identically.  :D</blockquote><div><br></div><div>Sorry, I don't know what you're talking about. I was saying that the syntax used in 1a has the same meaning as the syntax used in 3a (which is obviously identical to 1d), and the syntax of 3a/1d are a better way of expressing what 1a expresses. Maybe we're talking about subtly different things, but I don't think I'm wrong or confused here.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">However, (1d) is correct C++ code, whereas<br>
(3a) (which is identical in spelling) is a constraint violation<br>
requiring a diagnostic.</blockquote><div><br></div><div>I don't know what you mean here. 1d/3a is ill-formed in the same set of cases where 1a is ill-formed. (That is: ill-formed if it doesn't override a virtual function, and ill-formed if it would be overridden in a derived class.)</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
>> Here's what I think we should be recommending to people:<br>
>><br>
>> * A virtual function is marked with exactly one of 'virtual', 'override', or 'final'.<br>
>> * A new virtual function is marked 'virtual'.<br>
>> * An overriding, non-final virtual function is marked 'override'.<br>
>> * An overriding, final virtual function is marked 'final'.<br>
>><br>
>> This is minimally-verbose, each keyword means *exactly* one thing, and<br>
>> mistakes (where possible) result in code being ill-formed. This approach is<br>
>> already the one mandated by *every* style guide that I've seen take a<br>
>> position on this question.<br>
>><br>
>> Regardless of whether the above is your preferred direction, it is common,<br>
>> sane, reasonable, and correct, and any warning that warns on this approach<br>
>> has no place in Clang.<br>
<br>
</span>That makes sense.  FWIW (nothing), my preferred style would be<br>
 * A function is marked 'virtual' iff it is virtual.<br>
 * A virtual function is marked 'override' iff it is overriding.<br>
 * A virtual function is marked 'final' iff it is final.<br>
<br>
>> [T]he "you must write one of 'final' or 'override' if it's an<br>
<span class="">>> override and any other method in the class is marked as 'final' or<br>
>> 'override'" rule is much closer to being a correctness warning, and as a<br>
>> result it does the right thing for either style (or any other consistent<br>
>> style), so is a more reasonable thing to include in Clang.<br>
<br>
</span>I.e., the "Fariborz's current code, plus a special case where if we<br>
see a method that is overriding but not marked 'override', but it *is*<br>
marked 'final', then we suppress the usual 'override'-related warning"<br>
rule.  Makes sense to me.<br></blockquote><div><br></div><div>Yes, that's essentially the change I asked for.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
(Now this is no longer taking a position as to whether "final IMPLIES<br>
override." It's simply a good practical measure, intended to reduce<br>
the spamminess of this new warning on real code.)</blockquote><div><br></div><div>No "position" is required here; it is simply a fact that 'override final' is equivalent to 'final' when applied to a function that is not explicitly marked as 'virtual'.<br></div></div></div></div>