12.01.2017, 19:54, "Brady Eidson" <beid...@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* > 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.
I daresay nobody will object against auto in "cast experessions" as defined in [1], i.e. "calls to function templates" where "first template argument is explicit and is a type, and the function returns that type, or a pointer or reference to it". Examples: standard casts, downcast<>, dynamic_objc_cast<>, js(Dynamic)Cast. Also, it seems like there were no objections against auto t = std::make_unique<T>(...) [1] http://clang.llvm.org/extra/clang-tidy/checks/modernize-use-auto.html#cast-expressions > > 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> 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@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 > , > > _______________________________________________ > webkit-dev mailing list > webkit-dev@lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-dev -- Regards, Konstantin _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
