Re: Suggestion for N1984 auto proposal
Gene Bushuyev wrote:
"Peter Dimov" <pdimov@gmail.com> wrote in message
news:1153313462.985939.122910@h48g2000cwc.googlegroups.com...
"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 ) { ... }
Now tell me, why?
To aid clarity and remove risks of converting to a mismatching
type.
Why is it necessary in everyday code to save a few keystrokes
and lose clarity and thus to make coding more error-prone?
It is not; I don't think auto will do that. Rather, it will
reduce redundancy and make code simpler, more reliable, and
more readable.
In the above example, a programmer can say nothing about
> the type of iterator without looking at the container and
> retaining that in memory during the rest of the lifetime
> of "i".
Knowing that it's container_x<y>::iterator doesn't tell me
anything more useful than knowing that it is the type returned
by container_x<y>::begin(). A begin iterator is a begin
iterator, and had better act as one.
Also, I wouldn't be surprised if compilers start producing
cryptic messages when the implicit type and programmers
assumptions disagree.
I see no reason for that to be the case.
Language that allows that sort of constructs makes a disservice to the
programmers.
for(std::vector<auto,auto>::const_iterator i = c.begin(); i != c.end(); ++i )
{ ... }
This is not difficult to type, but it's free from all those problems.
It's less readable and still allows for conversion to the
wrong iterator type. (Do you also expect people to have
to remember how many template arguments std::vector really
has, when most users like to think of just the value type
and ignore defaulted template parameters?)
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:
I mentioned those cases not because it's not possibile to create rules how they
should be treated, but because they are not obvious or trivial. Complicated
rules is a recipe for programming errors as well as typos masquerading as
legitimate code.
[...]
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.
In order to do anything useful with iterator, it's good to know what type of
iterator it is, if it's random access or not makes a big difference, whether it
const or not makes a big difference, etc. The more constrained the problem is,
the easier it is to be solved correctly. Current "auto" proposal does just the
opposite; gratuitous obliteration of type doesn't help anything except saving a
few keystrokes.
It avoids duplication, it doesn't hide anything about the
*properties* of the iterator type that wasn't already hidden
behind a typedef, and it avoids the risk of mismatching
types. It's invaluable in templates, and I can see no
value in having a separate set of rules for non-templated
code.
-- James
---
[ 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 ]