Re: [lmi] Request for review

[Greg Chicares]

On 2017-01-12 16:33, Vadim Zeitlin wrote:
> On Thu, 12 Jan 2017 13:03:10 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> Rule 5: Always write ranged-for loops as 'for(auto&& ...'.
> GC> 
> GC> ...which is my new favorite.
> 
>  Sorry, I have to strongly disagree with this one. I really like to have an
> immediate visual indication that the container being iterated over is
> changed from the loop and "auto&&" doesn't give it. On a tangential note,
> as much as I appreciate STL's posts/ideas/cat utterances, I am glad his
> N3853 proposal was rejected, notwithstanding the official reason (shadowing
> of the variable with the same name outside the loop) IMO it was not worth
> the resulting loss of readability neither.
> 
>  In addition to my main problem with "auto&&" above, I also think it's
> significantly less clear what does it stand for. Both "auto&" and "auto
> const&" are, I think, pretty clear but "auto&&" can be much more difficult
> to resolve.

Okay. I don't seem to have much trouble changing my mind on this issue,
and I never really stopped liking Rule 2.

Let me ask one last question before I start working on this patch. STL's
proposal above has two distinct components:

 - always use the same for-range-declaration (regardless of constness);

 - always write that One True for-range declaration with two ampersands.

Are you saying "one ampersand good, two ampersands bad" for our general
rule--that it's the '&&' specifically that makes it harder to resolve?
(I can't claim to understand it well yet, but I had the impression that it
would give us more efficient "move" semantics, at least in some cases; but
you know what the Society of Actuaries motto says about impressions.)

If so, then it's agreed: we'll simply use Rule 2:

>  So the only rule which looks reasonable to me is:
> 
> GC> Rule 2:
> GC> - for(std::vector<T>::iterator ...
> GC> + for(auto& ...
> GC> - for(std::vector<T>::const_iterator ...
> GC> + for(auto const& ...

But if not, then would doubling the ampersands above improve Rule 2 IYO?

And thanks for demonstrating that auto and native types produce the same
object code at least in some meaningful cases.