Gene Bushuyev wrote:
> "Peter Dimov" <pdimov@gmail.com> wrote in message
> news:1153313462.985939.122910@h48g2000cwc.googlegroups.com...
> >
> > No, auto is most necessary in everyday code as in
> >
> > for( auto i = c.begin(); i != c.end(); ++i ) { ... }
>
> Now tell me, why? Why is it necessary in everyday code to save a few keystrokes
> and lose clarity and thus to make coding more error-prone?
> In the above example, a programmer can say nothing about the type of iterator
Except that is an iterator, and hence will support *, ->, and ++.
>
> 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.

Except that it breaks when the type of c changs from vector to deque
(for example).

It is also too verbose.  It hides the interesting information (that we
are iterating over the container) with a lot of template clutter.

---
[ 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                      ]

Martin Bonner wrote:
> Gene Bushuyev wrote:
>
>>"Peter Dimov" <pdimov@gmail.com> wrote in message
>>news:1153313462.985939.122910@h48g2000cwc.googlegroups.com...

>>for(std::vector<auto,auto>::const_iterator i = c.begin(); i != c.end(); ++i )
>>{ ... }


     I don't think that N1984 allows that.  There's no mention
in N1984 rev 4 of "auto" as a template argument.  As N1984
puts it, "A program that uses auto in a context not explicitly
allowed in this section is ill-formed".

    John Nagle
    Animats

---
[ 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                      ]

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? Why is it necessary in everyday code to save a few keystrokes
> and lose clarity and thus to make coding more error-prone?

I don't believe that the version with the explicit type is less
error-prone. There is the possibility of a type mismatch.

It's true that the typeful version gives you more information when
reading. Whether this makes it clearer is probably open to discussion
and depends on the audience.

> 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". Also, I wouldn't be surprised if compilers start producing
> cryptic messages when the implicit type and programmers assumptions disagree.

Compilers tend to do that all the time without auto. :-) If you supply
the wrong type, for example.

> 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 doesn't work. vector<auto, auto>::const_iterator is a non-deduced
context.

> >> 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.

The rules are already in the language. They aren't being created.

> >> 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.

You only use auto when you don't need to know all these things. What's
the problem?

---
[ 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                      ]

In article <dDvvg.132505$dW3.88201@newssvr21.news.prodigy.com>,
 "Gene Bushuyev" <spam@spamguard.com> wrote:

> > for( auto i = c.begin(); i != c.end(); ++i ) { ... }
>
> Now tell me, why? Why is it necessary in everyday code to save a few
> keystrokes
> and lose clarity and thus to make coding more error-prone?

So, does that mean you never make use of any of the standard algorithms?
After all, when writing something like:

   std::sort(c.begin(), c.end());

you aren't explicitly specifying the type of the iterator.

Or do you explicitly instantiate an algorithm on its iterator type(s)?


Heck, for that matter, do you ever use streams?  Expressions like:

   std::cout << v << std::endl;

don't have the type of v explicitly stated either.


auto is just an extension of the power we get with things like
overloading and function templates, where the exact type just doesn't
matter to the caller.

--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (773) 961-1620

---
[ 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                      ]

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? Why is it necessary in everyday code to save a few keystrokes
> and lose clarity and thus to make coding more error-prone?
> 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". Also, I wouldn't be surprised if compilers start producing
> cryptic messages when the implicit type and programmers assumptions disagree.
> Language that allows that sort of constructs makes a disservice to the
> programmers.

Below is a simple example where life is nearly impossible without auto
and, currently, faking it requires all sort of contortions and help
from the user for UDT's. See for example details of the required
contortions in Boost Lambda:

   http://www.boost.org/doc/html/lambda/extending.html

template <typename TL, typename TR>
void f(TL const & lhs, TR const & rhs)
{
    What_type t = lhs + rhs;
}

f(1, 2);  What_type is int
f(1, 2.); What_type is double
f(1., 2); What_type is double

regards
Andy Little

---
[ 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                      ]

"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                      ]

"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.

It's also useful in macros. I know we shouldn't use macros, but
sometimes it's necessary. And a piece of macro like
auto e1 = expr1;\
auto e2 = expr2;\
if (e1 != e2) { do_something_horrendous(e1, #expr1, e2, #expr2,
__FILE__, __LINE__) }

is quite useful when writing test code. I imagine someone helpful here
will post how to do this with templates and yet more macros, but.

Also, I've written the occasional piece of for loop where I really
don't want to remember exactly what type the iterator is, and
   for (auto iter = thing.begin(); iter != thing.end(); ++iter)

would save quite a lot of coding time. And it's clear enough to the
reader what is going on.

---
[ 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                      ]

"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? Why is it necessary in everyday code to save a few keystrokes
and lose clarity and thus to make coding more error-prone?
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". Also, I wouldn't be surprised if compilers start producing
cryptic messages when the implicit type and programmers assumptions disagree.
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.

>
> 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.

--
Gene Bushuyev (www.gbresearch.com)
----------------------------------------------------------------
To see what is in front of one's nose needs a constant struggle ~ George Orwell

---
[ 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                      ]

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                      ]

Gene Bushuyev wrote:
> "auto" in such unconstrained use is only a liability, it solves no real
> problems, but can be a source of logical errors and inefficiency. Programmer has
> to correctly figure out and remember the type that compiler will be assigning to
> auto. C++ was very successful with its strong typing, "auto" is undermining it.
>
> At the same time as a template type argument "auto" can be useful and not
> problematic:
>
> template<class C>
> void foo(const C& container)
> {
>     typename std::vector<auto, auto>::iterator i = container.begin();
>     // we have plenty of type information now, and
>     // type deduction is constrained to a suitable container
> }

And unless I'm very much mistaken, it doesn't work. Isn't that a
non-deduced context?


> So my suggestion is to modify N1984 to allow "auto" only as a template type
> argument, which should be deduced in accordance with existing template argument
> deduction rules.
>

If you feel that increases readability, go ahead and use it like that,
but that's no reason to disallow everyone else from using it the way
they feel is most useful.

Yechezkel Mett

---
[ 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                      ]

On Wed, 19 Jul 2006 16:26:13 -0600, Gene Bushuyev wrote:

>> No, auto is most necessary in everyday code as in
>>
>> for( auto i = c.begin(); i != c.end(); ++i ) { ... }
>
> Now tell me, why? Why is it necessary in everyday code to save a few keystrokes
> and lose clarity and thus to make coding more error-prone?

There is no loss: see below:

> for(std::vector<auto,auto>::const_iterator i = c.begin(); i != c.end(); ++i )
> { ... }
>
> This is not difficult to type,

You're kidding right?

you do realise many advanced language *heavily* emphasise
the advantage of complete type inference? I'm not advocating
that .. and neither is the 'auto' proposal.

Instead, auto variables allow you to factor and simplify
statements such as:

 int i = f (g (x) );

into

 auto tmp = g (x);
 int i = f (tmp);

In this case you can see clearly there is no loss of
an explicit type annotation .. because in the original
form the subexpression 'g (x)' did not posses an
explicit type annotation in the first place.

In the case of a loop:

 for( auto i = c.begin(); i != c.end(); ++i ) {
  float v = *i; other.push_back(v); ...
 }

offers major advantages in 'cut and paste' genericity,
including templates, precisely because it does NOT name
the type. In particular, this body of code is
polyadic (aka functorially polymorphic or generic) which
means it is independent of the container type of c. We do
not CARE what the type of either the container or iterator
is .. all we care about is that the algorithm iterates over
the values of the container. This means we can easily
make the code work when C is a vector.. and replace it
later with a list without modifications.

Roughly speaking this extension would reduce the need
for crud in STL containers like:

 class Container .. {  typedef ... iterator_type; .. }

which is needed mainly to compensate for the *lack*
of type deduction.

--
John Skaller <skaller at users dot sf dot net>
Try Felix, the successor to C++ http://felix.sf.net


---
[ 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                      ]

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.

int foo();
auto& x = foo(); // error? why not auto = const int?
auto y = foo(); // is it intended or a typo?
auto long z = foo(); // an existing meaning

struct A
{
};
const A& bar();
auto a = bar(); // should the auto type be A or const A&?
auto&& b = bar(); // is that allowed?

template<class C>
void foo(const C& container)
{
    auto i = container.begin();
    // can we do much useful with "i" not knowing its type?
}

"auto" in such unconstrained use is only a liability, it solves no real
problems, but can be a source of logical errors and inefficiency. Programmer has
to correctly figure out and remember the type that compiler will be assigning to
auto. C++ was very successful with its strong typing, "auto" is undermining it.

At the same time as a template type argument "auto" can be useful and not
problematic:

template<class C>
void foo(const C& container)
{
    typename std::vector<auto, auto>::iterator i = container.begin();
    // we have plenty of type information now, and
    // type deduction is constrained to a suitable container
}

In metaprogramming:

template<class A, class B> class plus_proxy { /* ... */};

template<class A, class B> plus_proxy<A,B> operator + (A a ,B b)
{ return plus_proxy<A,B>(a,b); }

SomeType a,b,c, ...;

auto result = a + b + c + ...; // obliterates useful type information

plus_proxy<auto, auto> result = a + b + c + ...; // useful and safe

auto p = make_pair(a,b); // not useful

std::pair<auto, auto> p(a,b); // not only useful, it eliminates the need of
duplicating all constructors with helper functions like make_pair(), the only
purpose of which is argument type deduction

So my suggestion is to modify N1984 to allow "auto" only as a template type
argument, which should be deduced in accordance with existing template argument
deduction rules.

--
Gene Bushuyev (www.gbresearch.com)
----------------------------------------------------------------
To see what is in front of one's nose needs a constant struggle ~ George Orwell

---
[ 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                      ]