auto (was Most needed/desired features in C++)

From: Fernando Cacciola (fcacciola_at_[hidden])
Date: 2002-02-19 13:23:27

I'm afraid that even after having read all these messages about 'auto return
types', I still feel that this feature is more dangerous than useful. I'm
not refering to auto for variable declaration but for return types.

To show my point, let's see some of these examples:

>template<class T, class S>
>      operator+(T &t, S &s)

>        v = t+s;                // type of v is implicit
>        return v;               // return type is implicit
>      }
>
In this case, operator +() would involve an implicit conversion, but, even
worse, because the implicit conversion would convert to an implicit type, so
the indirection is doubled.
All known potential problems with implicit conversions would appear twice
with auto return types, because AFAICT, auto return types will always
require an implicit conversion to an implicit type.

>
>template<typename T, int I>
>auto foo(T t, T* pt, double a, std::string b){
> //...
>}
>
Why would the return type of foo() has anything to do with T, doube or
std::string?
Trying to guess what is the type of a result based on the argument types is
plain wrong.
The return type could be "anything" + T and it is only determined by a
return expression.

>
>template<typename T1, typename T2>
>auto min(T1 t1, T2 t2)
>{
>   if (t1 < t2) return t1;
>   else return t2;
>}

This example won't behave as intended.
The type of foo() (the return type), is determined at runtime, not compile
time.
'auto' here would actually mean 'boost::any', but we are considering a
compile-time type deduction, not a dynamic typing.

This example, however, pops up an important thing:

The type of the result of a function can ONLY be determined by its return
expression. As I pointed out, it cannot be determined by the function
arguments becuase there is no reason why a function should return a type
associated with the type of its arguments.

But a return expression can only have a fixed known-at-compile-time type. It
doesn't matter which sort of type deduction is used, the type must be fixed,
otherwise, we are talking about true dynamic typing as in 'min' above, but
we don't want that.

Therefore, 'auto' for a return type will allow implicit conversions to an
implicit type.

The only case when it will guarantee no implicit conversions is when a
single auto variable is used for the return expresion:

auto foo()
{
   auto r = some();
   return r ;
}

If the return expression includes anything else, including more than one
auto variables, it could involve an implicit conversion.

auto foo()
{
  auto a = someA();
  auto  b = someB();
  return choose_one() ? a : b ;  // posible implicit conversion here.
}

Just as I wear the hat of 'don't use implicit conversions', I would wear the
hat of "don't use auto return types" if they were allowed.

I do however, support the 'auto' for variable declaration because there is
not a conversion involved even though the type is implicit.

Fernando Cacciola
Sierra s.r.l.
fcacciola_at_[hidden]
www.gosierra.com