> On Jan 12, 2017, at 08:54, Brady Eidson <[email protected]> wrote: > > 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&
In some cases you need a copy for the code to be correct. I understand why & is often better for performance but there is a significant and dangerous behavioral difference. I agree with encouraging people to use auto& because it's usually ok, but I disagree with mandating it because it's sometimes wrong. -Filip > > 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 <[email protected]> wrote: >> >> >> >>> On Jan 11, 2017, at 11:15 AM, JF Bastien <[email protected]> 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 >>> [email protected] >>> https://lists.webkit.org/mailman/listinfo/webkit-dev >> _______________________________________________ >> webkit-dev mailing list >> [email protected] >> https://lists.webkit.org/mailman/listinfo/webkit-dev > > _______________________________________________ > webkit-dev mailing list > [email protected] > https://lists.webkit.org/mailman/listinfo/webkit-dev
_______________________________________________ webkit-dev mailing list [email protected] https://lists.webkit.org/mailman/listinfo/webkit-dev
