On 2015-04-29 9:17 PM, Karl Tomlinson wrote:
Ehsan Akhgari writes:
I think there's a typo of some sort in the question, but if you
meant "every overriding function must be marked with override",
then yes, that is the change I'm proposing, but the good news is
that you can now run clang-tidy on the entire tree and get it to
rewrite the source code to make sure that the override keywords
are present where they are needed, and we can do that as often as
we would like. IOW, this can be done without requiring every C++
programmer to remember to do it always.
I fear that an automatic update would be more than just enforcing
a style because override keywords imply programmer intent.
If the proposal is to periodically automatically add override
keywords where methods override but are currently not annotated as
such
Yes, I would like us to get to that point (but running the tool needs to
be done manually for now.)
> then it seems we should we have an annotation to indicate
that a method is not intended to override.
However, that would require annotating all methods.
I don't understand what you're suggesting. Adding override to an
overriding virtual function doesn't change what the program means.
There is no need to annotate all methods.
(Please note that my proposal works very well in other large well
established code bases. I'm not exactly making up a new rule!)
This seems similar to the compiler warning situation.
Usually at least, I don't think we should automatically modify the
code in line with how the compiler reads the code just to silence
the warning. Instead the warning is there to indicate that a
programmer needs to check the code.
These cases bear no similarity whatsoever. I can't think of any
compiler warnings that can be automatically fixed without changing the
meaning of the program.
Perhaps though there is a case for a one-off change to add
override automatically so that warnings can be enabled on new
code.
Again, I'm not sure what you're mentioning exactly, but my proposal
entails periodic automatic rewrites of the code without changing what
the code means. And hopefully people will start to gradually obey the
new coding style.
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
