Bug 127506 – Avoid unnecessary copies in range-based for-loops

• Status: NEW
• Component: New Bugs

[Zan Dobersek]

In around 20 files range-based for-loops are used that assign each iterated value to an inferred non-reference type, causing copies:

    for (auto elem : range) { ... }

auto& or const auto& should be used instead.

Using auto&& in these loops would be the perfect solution, and there are plans to further simplify the range-based for-loops in the future based on using that type. I don't know if using auto&& now would be feasible for the project.
http://open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3853.htm

[Zan Dobersek]

Created attachment 222019 [details]
Patch

[Brent Fulgham]

(In reply to comment #0)
> Using auto&& in these loops would be the perfect solution, and there are plans to further simplify the range-based for-loops in the future based on using that type. I don't know if using auto&& now would be feasible for the project.
> http://open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3853.htm

What would be the problem with using auto&& now? It's valid on all compilers we support, isn't it?

[Zan Dobersek]

(In reply to comment #2)
> (In reply to comment #0)
> > Using auto&& in these loops would be the perfect solution, and there are plans to further simplify the range-based for-loops in the future based on using that type. I don't know if using auto&& now would be feasible for the project.
> > http://open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3853.htm
> 
> What would be the problem with using auto&& now? It's valid on all compilers we support, isn't it?

It should be (haven't tested out MSVC). I'm concerned whether it would be possible to enforce the use of auto&& through the style guidelines and whether the relative complexity overhead is acceptable until all the supported compilers actually support the simplified syntax.

[Zan Dobersek]

Comment on attachment 222019 [details]
Patch

This patch needs updating.

[Alexey Proskuryakov]

> What would be the problem with using auto&& now? It's valid on all compilers we support, isn't it?

FWIW, I'm still not sure what the benefit would be. My understanding is that auto&& is superior for library code, where it allows for a wider range of types to work. But in normal WebCore code, isn't it best to use the most specific form that compiles? Less generality makes code more readable.

In other words, I'd suggest that we prefer auto& or const auto&, and only use auto&& when that's required for successful compilation.