[webkit-dev] [webkit-reviewers] usage of auto

Saam barati sbarati at apple.com
Tue Jan 17 11:34:20 PST 2017

> On Jan 12, 2017, at 10:37 AM, Geoffrey Garen <ggaren at 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 at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-dev/attachments/20170117/111f911b/attachment.html>

More information about the webkit-dev mailing list