[webkit-dev] [webkit-reviewers] usage of auto

[Konstantin Tokarev]

12.01.2017, 19:54, "Brady Eidson" <beidson at apple.com>:
> My take-away from this discussion so far is that there is actually very little consensus on usage of auto, which means there’s probably very little room for actual style guideline rules.
>
> I think there are two very limited rules that are probably not objectionable to anybody.
>
> 1 - If you are using auto for a raw pointer type, you should use auto*

This rule seems to be very useful if we can enforce that * is never acidentally dropped.

> 2 - If you are using auto in a range-based for loop for values that aren’t pointers, you should use (const) auto&
>
> If there’s no objections to these rules, I think it’s valuable to have them in the style guidelines at the very least.
>
> Thanks,
> ~Brady
>
>> On Jan 11, 2017, at 10:27 PM, saam barati <saambarati1 at gmail.com> wrote:
>>
>> On Jan 11, 2017, at 11:15 AM, JF Bastien <jfb at chromium.org> wrote:
>>
>>> Would it be helpful to focus on small well-defined cases where auto makes sense, and progressively grow that list as we see fit?
>>>
>>> e.g. I think this is great:
>>>> auto ptr = std::make_unique<Foo>(bar);
>>> Proposed rule: if the type is obvious because it's on the line, then auto is good.
>>> Similarly:
>>>> auto i = static_cast<int>(j);
>>>> auto foo = make_foo();
>>>> auto bar = something.get_bar(); // Sometimes, "bar" is obvious.
>> I'm not sure I agree with this style. There are times where the type of an auto variable is obvious-enough, but it's almost never more obvious than actually writing out the types. Writing out types, for my brain at least, almost always makes the code easier to understand. The most obvious place where I prefer auto over explicit types is when something has a lot of template bloat.
>>
>> I feel like the places where auto makes the code better are limited, but places where auto makes the code more confusing, or requires me to spend more time figuring it out, are widespread. (Again, this is how my brain reads code.)
>>
>> Also, I completely agree with Geoff that I use types to grep around the source code and to figure out what data structures are being used. If we used auto more inside JSC it would hurt my workflow for reading and understanding new code.
>>
>> - Saam
>>
>>> Range-based loops are a bit tricky. IMO containers with "simple" types are good candidates for either:
>>>> for (const auto& v : cont) { /* don't change v */ }
>>>> for auto& v : cont) { /* change v */ }
>>> But what's "simple"? I'd say all numeric, pointer, and string types at least. It gets tricky for more complex types, and I'd often rather have the type in the loop. Here's more discussion on this, including a recommendation to use auto&& on range-based loops! I think this gets confusing, and I'm not a huge fan of r-value references everywhere.
>>>
>>> Here's another I like, which Yusuke pointed out a while ago (in ES6 Module's implementation?):
>>>> struct Foo {
>>>>   typedef Something Bar;
>>>>   // ...
>>>>   Bar doIt();
>>>> };
>>>> auto Foo::doIt() -> Bar
>>>> {
>>>>   // ...
>>>> }
>>> Why? Because Bar is scoped to Foo! It looks odd the first time, but I think this is idiomatic "modern" C++.
>>>
>>> I also like creating unnamed types, though I know this isn't everyone's liking:
>>>> auto ohMy()
>>>> {
>>>>   struct { int a; float b; } result;
>>>>   // ...
>>>>   return result;
>>>> }
>>>> void yeah()
>>>> {
>>>>   auto myMy = ohMy();
>>>>   dataLogLn(myMy.a, myMy.b);
>>>> }
>>> I initially had that with consumeLoad, which returns a T as well as a ConsumeDependency. I couldn't care less about the container for T and ConsumeDependency, I just want these two values.
>>> _______________________________________________
>>> webkit-dev mailing list
>>> webkit-dev at lists.webkit.org
>>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> ,
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev


-- 
Regards,
Konstantin