Re: Suggestion for N1984 auto proposal
"Gene Bushuyev" wrote:
You can find in the current auto proposal
(http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2006/n1984.pdf) some
problematic moments with "unconstrained" use of auto, like weird reference
rules, unintended aliasing and slicing, confusion with existing auto rules.
In reality, auto is most necessary in template metaprogramming where it's also
the least problematic, and it's both unnecessary and problematic in
unconstrained expressions.
No, auto is most necessary in everyday code as in
for( auto i = c.begin(); i != c.end(); ++i ) { ... }
or
auto f = bind( g, _1, 5 );
int foo();
auto& x = foo(); // error? why not auto = const int?
The semantics of auto are derived from template argument deduction. In:
auto ... id = expr;
the type behind 'auto' is determined as in:
template<class Auto> void helper( Auto ... id );
helper( expr );
Since Auto & id will deduce Auto as int and not as int const,
auto& x = foo();
is equivalent to
int& x = foo();
auto y = foo(); // is it intended or a typo?
Intended.
auto long z = foo(); // an existing meaning
struct A
{
};
const A& bar();
auto a = bar(); // should the auto type be A or const A&?
A. See above.
auto&& b = bar(); // is that allowed?
Allowed, equivalent to
A const& b = bar();
template<class C>
void foo(const C& container)
{
auto i = container.begin();
// can we do much useful with "i" not knowing its type?
Yes, everything we need. Iterator types are typically opaque. We
usually know that C::const_iterator is an alias for the correct type,
but the real type is unknown in general.
}
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]