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* 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 <saambara...@gmail.com> wrote: > > > > On Jan 11, 2017, at 11:15 AM, JF Bastien <j...@chromium.org > <mailto:j...@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 >> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3853.htm>, >> 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 >> <https://github.com/WebKit/webkit/blob/master/Source/WTF/wtf/Atomics.h#L385>, >> 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@lists.webkit.org <mailto:webkit-dev@lists.webkit.org> >> https://lists.webkit.org/mailman/listinfo/webkit-dev >> <https://lists.webkit.org/mailman/listinfo/webkit-dev> > _______________________________________________ > webkit-dev mailing list > webkit-dev@lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-dev
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
