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

From: brianjparker (brianjparker_at_[hidden])
Date: 2002-02-19 23:50:17

--- In boost_at_y..., "Fernando Cacciola" <fcacciola_at_g...> wrote:
> >
> >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.

The auto in the min() function example would be a well-defined 
compile-time-deduced type- it would be the common conversion type of 
all return paths (which is just extended version of the type 
conversion rules of operator ?: ). A min function that takes 
arbitrary arguments *must* have as a return type the common 
conversion type of the arguments, so one way or another you will need 
to deduce this common type and cast the arguments to it; "auto" (or 
my preferred template<typename R> syntax) just makes this convenient 
and obvious.

As you say, in the case where there is a single return path, or all 
return paths return the same type then the function return will be of 
that type; and the case where different convertible types are 
returned then one or more of them will involve an implicit conversion 
to the common conversion type (just like ?:). 

This is a feature- computing the common conversion type of several 
types is essential for writing fully generic functions that take 
arbitrary arguments. 

,Brian Parker