> 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

Reply via email to