[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