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
Created attachment 222019 [details] Patch
(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?
(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.
Comment on attachment 222019 [details] Patch This patch needs updating.
> 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.