[cfe-dev] RFC: clang-tidy readability check to reduce clutter: unnecessary use of auto and ->

Richard via cfe-dev cfe-dev at lists.llvm.org
Sat Nov 7 09:18:39 PST 2015


[Please reply *only* to the list and do not include my email directly
in the To: or Cc: of your reply; otherwise I will not see your reply.
Thanks.]

In article <563DC703.4000507 at gmx.net>,
    Fabio Fracassi via cfe-dev <cfe-dev at lists.llvm.org> writes:

> Hi,
> 
> On 06/11/2015 19:08, Richard via cfe-dev wrote:
> [...]
> > N2541 <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2541.htm>
> > introduced auto and the trailing return type syntax.
> >
> > Now people are using auto and -> on function signatures where the
> > return type is stated explicitly anyway.  This results in code like:
> >
> > auto main() -> int
> > {
> >    return 0;
> > }
> so?
> 
> > Srsly?  Is this really improving anything over
> >
> > int main()
> > {
> >    return 0;
> > }
> no, but it is not worse either.
> 
> > To me this is introducing unnecessary clutter
> it is more uniform,

It *is* more clutter in the sense that it introduces unnecessary tokens.

clang-tody's modernize transformation that uses override eliminates the
unnecessary keyword virtual because it is clutter that isn't needed.
One could argue against this saying "it is more uniform" to use virtual
on all virtual methods, even those with the keyword override.

Similarly, one can argue for uniformity in using 'void f(void);'
instead of 'void f();' but here the extra 'void' in the argument list
adds nothing and is merely clutter.  Command methods (as in
command/query separation; google it if you're unfamiliar with the
design principle) return void.  Writing 'auto f() -> void;' obscures
that this is a command until I get to the end of the declaration.  In
fact writing 'auto' puts me immediately in the mindset of "this
function is going to return a value" only to make me change my mind
when I reach the end and learn "oh, the value is void."

> and for mathematically inclined people it is also 
> more natural.

I didn't know you were appointed spokesman for all mathematically
inclined people?  Seriously, I'm a mathematically inclined person and
I don't find this more natural.

> just because it is a new syntax it doesn't  make it more cluttered or 
> anything.

To me, clutter is adding extra stuff in that's not necessary like
(void) argument lists or gratuitous use of auto.

> Herb Sutter recommends this style in his Almost Always Auto article:

I assume you are talking about this:
<http://herbsutter.com/2013/08/12/gotw-94-solution-aaa-style-almost-always-auto/>

That article is from 2013 and in subsequent talks on YouTube I've
seen people comment that "whacking everything with an auto hammer"
doesn't yield the benefits that were claimed at the time.  Furthermore,
just because Herb Sutter likes a certain style doesn't mean that I do.

With clang-tidy we're not talking about the compiler creating a warning
or error because you use a certain code construct.  clang-tidy is
like clang-format.  You don't like LLVM code formatting conventions?
Nothing's forcing you to use them.

> > and isn't the reason why
> > auto and -> for function return types were introduced.
> certainly not, but it is a nice side effect.

I read the paper at the link I posted before sending the email.
While the author of the paper doesn't state a rationale or design
motivation for the paper -- because it is simply a list of diffs to be
applied to the standard -- I think it is pretty clear what is motivating
the new syntax because of the examples.  I suppose if we really want to
settle this fine point we can email the authro Jason Merrill and ask him.
I haven't attempted to do so.
-- 
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
     The Computer Graphics Museum <http://ComputerGraphicsMuseum.org>
         The Terminals Wiki <http://terminals.classiccmp.org>
  Legalize Adulthood! (my blog) <http://LegalizeAdulthood.wordpress.com>



More information about the cfe-dev mailing list