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

JF Bastien jfb at chromium.org
Wed Jan 11 11:15:29 PST 2017


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.



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
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3853.htm>,
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
<https://github.com/WebKit/webkit/blob/master/Source/WTF/wtf/Atomics.h#L385>,
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-dev/attachments/20170111/7f4556bf/attachment.html>


More information about the webkit-dev mailing list