> On Jan 12, 2017, at 10:37 AM, Geoffrey Garen <gga...@apple.com> wrote:
> 
>>> 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.
> 
> In the first case, static_cast<int>, the type is written out on the same 
> line. Same goes for other casts, make_unique<T>, and so on. Would you accept 
> auto in those cases? If not, what benefit do you get from seeing the type 
> twice on one line?

My reason I don't like this style is it slightly changes how I read code. I 
typically look at the lhs of an expression to get its type.
Now, I may have to look at the lhs, and maybe at some compound expression on 
the rhs. I just don’t see the point of this
to save a few characters.

For cases like jsDynamicCast, std::make_unique, etc, I also have to know what 
those functions do. This is obvious to experienced JSC/C++ developers, but 
maybe not to all newcomers to the code base.

All that said, this usage of auto probably bothers me the least out of all the 
usages I don’t like.

- Saam

> 
> I think the second and third cases are somewhat rare in WebKit, and I might 
> agree against using auto. For example:
> 
> RefPtr<T> thing;
> auto* context = something.context();
> context->setThing(thing.get()); // I need to research why context->thing is 
> allowed to be a raw pointer, but I don’t know what context is.
> 
> Geoff
> _______________________________________________
> 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