Re: [lmi] Request for review

[Vadim Zeitlin]

On Fri, 13 Jan 2017 01:10:34 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2017-01-12 22:50, Vadim Zeitlin wrote:
...
GC> >  My main problem with "auto&&" is that it loses "const" and so doesn't
GC> > indicate the intention of the code to not modify or modify the container.
GC> > Both are important and without one we can't have the other.
GC> 
GC> Then we can't write anything like 'auto const&&' or 'auto &const&'?

 We can write the former but it would only bind to r-value references and
I'm not sure what would be the point of that in this context. We can't
write the latter because references to references are (still) not allowed.

GC> But don't answer that; I wouldn't understand the answer. (It reminds me
GC> of the time a colleague was entering a command on an IBM 5150 and I,
GC> my experience being limited to the 5110, asked him what the backslash
GC> character meant. I'm sure he explained that it referred to a directory,
GC> but without the "directory" concept I couldn't understand his answer.)

 I tried very hard to not use the word "directory" in my answer above to
avoid this problem.


GC> Although it shouldn't have been associated with std::vector<bool>, a
GC> bitset with one bit of storage per bit of boolean data is a great idea.

 It has its uses, yes, it just should have never been called a vector.

GC> Citing its original statement again:
GC> 
GC> - for(std::vector<T>::iterator ...
GC> + for(auto& ...
GC> - for(std::vector<T>::const_iterator ...
GC> + for(auto const& ...
GC> 
GC> IOW, when translating a non-ranged 'for' to a ranged 'for':
GC>   for ( for-range-declaration : expression ) statement
GC> where
GC>   for-range-declaration: attribute-specifier-seq[opt] decl-specifier-seq 
declarator
GC> our rule requires:
GC>  (1) no attribute-specifier-seq shall be used;
GC>  (2) the decl-specifier-seq shall be either 'auto' or 'auto const',
GC>      whichever is more appropriate in context;
GC>  (3) the declarator shall include the '&' ref-qualifier.
GC> 
GC> Rationale:
GC> 
GC> (1) We don't care about the alignment (e.g.) of iterators.
GC> 
GC> (2) 'auto' is preferred to the actual type for uniformity (all ranged-for
GC> constructs are written the same way) and robustness (if the container's
GC> datatype changes, an explicitly-specified actual type would need to be
GC> edited; but the deduced type adapts automatically, and the compiler
GC> guarantees that it is correct). 'const' is to be written wherever
GC> appropriate because it expresses the intent clearly, and allows us to
GC> write a for-statement that cannot alter its container even if the
GC> container itself is not physically const.
GC> 
GC> (3) Const references cost nothing (according to your tests) if the deduced
GC> type is primitive; otherwise, they save the overhead of copying. Non-const
GC> references, where written through, are generally required for correctness
GC> (and, if not written through, they should be const anyway).

 FWIW I agree with everything above, thanks for spelling it out!
VZ