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

[Tim Halloran via cfe-dev]

While this seems like a good idea, perhaps the tidy it should examine the
complexity of the type being "auto"ed. The new return value syntax seems
good to move a long type to the end of a function declaration to help code
clarity, even if it is not strictly necessary.

auto f() -> my_super_duper<long,long,long,long,long> {
  ...
}

A simple type name (e.g., int or Airplane) seems okay to do the proposed
refactoring, beyond that seems less of a clarity win to me.


On Fri, Nov 6, 2015 at 1:08 PM, Richard via cfe-dev <cfe-dev at lists.llvm.org>
wrote:

> [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.]
>
> Hello tidy programmers,
>
> There seems to be a certain breed of programmer that once having
> learned a new feature of C++ intends to get out their new feature
> hammer and bang on everything in sight.
>
> Case in point:
>
> 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;
> }
>
> Srsly?  Is this really improving anything over
>
> int main()
> {
>   return 0;
> }
>
> To me this is introducing unnecessary clutter and isn't the reason why
> auto and -> for function return types were introduced.
>
> I would like to propose a clang-tidy readability check that turns the
> former into the latter when the return type doesn't use anything that
> needs auto.  In other words, this code would be left alone:
>
> template <typename T, typename U>
> auto add(T x, U y) -> decltype(x + y)
> {
>   return x + y;
> }
>
> There is one note in N2541 that states how the new syntax eliminates
> an ambiguity with this example:
>
> auto f() -> int (*)[4];
> // function returning a pointer to array[4] of int,
> // not function returning array[4] of pointer to int.
>
> This seems to be another case that should be left unchanged.
>
> Proposed check name: readability-redundant-auto-return-type
>
> What are your thoughts?
> --
> "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>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>



-- 
Tim Halloran
SureLogic, Inc.
5808 Forbes Avenue, Pittsburgh PA 15217-1602
(412) 722-3338
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20151106/9c08f259/attachment.html>