llvm dev - Dec 2018 - [cfe-dev] RFC: Modernizing our use of auto

> On Dec 4, 2018, at 10:59 AM, George Burgess IV <george.burgess.iv at
gmail.com> wrote:
> 
> > I think people are too eager to use `auto` because it is easy to write
but it makes the types substantially harder for the reader to understand
> 
> I'm probably the Nth person to ask this, but what keeps us from
promoting the use of a clang-tidy-powered tool that basically emits fixits of
s/auto/actual_type/?
Because the tool would need to apply judgement to when this makes sense.  If we
can’t write an algorithm in coding standards.html to be prescriptive about when
to use auto, then I don’t think we can automate this.

-Chris

So the problem becomes one of seeing if people will accept `auto` rules
that don't require substantial amounts of thought.

Personally, I see this like our use of clang-format. It might not use my
favorite color of paint, but it's uniform, automatic, and it lets me
entirely forget about tons of style nits, so I love it to death. Hence, if
we need to start with "no auto, except in this small set of trivially OK
and machine-verifiable cases, which we'll consider expanding this as need
arises," to get to that, I'd be all for it.

I realize that many devs probably strongly disagree with me here, but
that's my 2c.

On Wed, Dec 5, 2018 at 9:26 PM Chris Lattner <clattner at nondot.org>
wrote:
>
>
> > On Dec 4, 2018, at 10:59 AM, George Burgess IV <
> george.burgess.iv at gmail.com> wrote:
> >
> > > I think people are too eager to use `auto` because it is easy to
write
> but it makes the types substantially harder for the reader to understand
> >
> > I'm probably the Nth person to ask this, but what keeps us from
> promoting the use of a clang-tidy-powered tool that basically emits fixits
> of s/auto/actual_type/?
>
> Because the tool would need to apply judgement to when this makes sense.
> If we can’t write an algorithm in coding standards.html to be prescriptive
> about when to use auto, then I don’t think we can automate this.
>
> -Chris
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20181205/010580fa/attachment.html>

I agree with George here, the current implementation of modernize-use-auto
<http://clang.llvm.org/extra/clang-tidy/checks/modernize-use-auto.html>
uses
pretty much the same rules as described in our coding standards which we
all agree on, mainly:
- iterators (begin, end)
- cast expressions
- new expression

Ofc there are more cases where type is obvious and where we would like to
use auto, but automating the part that modernize-use-auto can do is enough
to cover most of the cases.

Cheers
Piotr

czw., 6 gru 2018 o 08:46 George Burgess IV via cfe-dev <
cfe-dev at lists.llvm.org> napisał(a):
> So the problem becomes one of seeing if people will accept `auto` rules
> that don't require substantial amounts of thought.
>
> Personally, I see this like our use of clang-format. It might not use my
> favorite color of paint, but it's uniform, automatic, and it lets me
> entirely forget about tons of style nits, so I love it to death. Hence, if
> we need to start with "no auto, except in this small set of trivially
OK
> and machine-verifiable cases, which we'll consider expanding this as
need
> arises," to get to that, I'd be all for it.
>
> I realize that many devs probably strongly disagree with me here, but
> that's my 2c.
>
> On Wed, Dec 5, 2018 at 9:26 PM Chris Lattner <clattner at nondot.org>
wrote:
>
>>
>>
>> > On Dec 4, 2018, at 10:59 AM, George Burgess IV <
>> george.burgess.iv at gmail.com> wrote:
>> >
>> > > I think people are too eager to use `auto` because it is easy
to
>> write but it makes the types substantially harder for the reader to
>> understand
>> >
>> > I'm probably the Nth person to ask this, but what keeps us
from
>> promoting the use of a clang-tidy-powered tool that basically emits
fixits
>> of s/auto/actual_type/?
>>
>> Because the tool would need to apply judgement to when this makes
sense.
>> If we can’t write an algorithm in coding standards.html to be
prescriptive
>> about when to use auto, then I don’t think we can automate this.
>>
>> -Chris
>>
>>
>> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20181206/51954a4d/attachment.html>

On Wed, Dec 5, 2018, 9:27 PM Chris Lattner via cfe-dev <
cfe-dev at lists.llvm.org wrote:
>
>
> > On Dec 4, 2018, at 10:59 AM, George Burgess IV <
> george.burgess.iv at gmail.com> wrote:
> >
> > > I think people are too eager to use `auto` because it is easy to
write
> but it makes the types substantially harder for the reader to understand
> >
> > I'm probably the Nth person to ask this, but what keeps us from
> promoting the use of a clang-tidy-powered tool that basically emits fixits
> of s/auto/actual_type/?
>
For me: I still don't know how to integrate clang-tidy into my development
workflow. I'm open to pointers to documentation/etc.

Because the tool would need to apply judgement to when this makes
sense.
> If we can’t write an algorithm in coding standards.html to be prescriptive
> about when to use auto, then I don’t think we can automate this.
>
Yeah, I don't think we can automate it entirely, but at least it might
lower the writing cost to make it easier for folks favoring auto for
writability where community standards would prefer the named type. Nice
thing about clang-tidy etc is if integrated well, it should only flag on
code in the current diff, and only as a suppressible suggestion not a hard
requirement.

I think if folks want to work on that, it'd be appreciated, but I don't
think it changes the discussion around what style we want.



> -Chris
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20181206/d1b52f47/attachment.html>

> On Dec 6, 2018, at 11:37 AM, David Blaikie via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> 
> 
>> On Wed, Dec 5, 2018, 9:27 PM Chris Lattner via cfe-dev <cfe-dev at
lists.llvm.org wrote:
>> 
>> 
>> > On Dec 4, 2018, at 10:59 AM, George Burgess IV
<george.burgess.iv at gmail.com> wrote:
>> > 
>> > > I think people are too eager to use `auto` because it is easy
to write but it makes the types substantially harder for the reader to
understand
>> > 
>> > I'm probably the Nth person to ask this, but what keeps us
from promoting the use of a clang-tidy-powered tool that basically emits fixits
of s/auto/actual_type/?
> 
> 
> For me: I still don't know how to integrate clang-tidy into my
development workflow. I'm open to pointers to documentation/etc.
Not sure if this helps, but CMake actually added support for integrating
clang-tidy with your build:
https://cmake.org/cmake/help/latest/prop_tgt/LANG_CLANG_TIDY.html

I haven’t used it with LLVM because LLVM and Clang aren’t clang-tidy clean, but
I do use it on other projects that are, and it works really well.

-Chris
> 
>> Because the tool would need to apply judgement to when this makes
sense.  If we can’t write an algorithm in coding standards.html to be
prescriptive about when to use auto, then I don’t think we can automate this.
> 
> 
> Yeah, I don't think we can automate it entirely, but at least it might
lower the writing cost to make it easier for folks favoring auto for writability
where community standards would prefer the named type. Nice thing about
clang-tidy etc is if integrated well, it should only flag on code in the current
diff, and only as a suppressible suggestion not a hard requirement.
> 
> I think if folks want to work on that, it'd be appreciated, but I
don't think it changes the discussion around what style we want.
> 
> 
> 
>> 
>> -Chris
>> 
>> 
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20181206/10bf5019/attachment.html>