From: brianjparker (brianjparker_at_[hidden])
Date: 2002-02-19 22:14:37
--- In boost_at_y..., "danl_miller" <danl_miller_at_b...> wrote:
>...
> Currently, I myself do not consider the difference between C's
> auto foo;
> to deduce foo to be an int versus the proposed C++
> auto foo = "example";
> to be a const char* as an important smoking-gun counter-example.
> Likewise, I myself do not consider the difference between C's
> acceptance of
> auto foo;
> versus C++'s rejection of [in the proposed implied-type declaration
> usage of auto]
> auto foo;
> due to lack of initialization from which to deduce the implied type
to
> be an important smoking-gun counter example.
>
> --- In boost_at_y..., "brianjparker" <brianjparker_at_h...> wrote:
> > ...
> > My major objection to the "auto" proposal is its syntax- I think
> that
> > one can achieve the same result as a pure extension without
> > overloading a keyword (or introducing a new keyword) by simply
> > extending to function return and local variables the existing
type
> > deduction rules applied to function arguments.
> > e.g. in
> >
> > template<typename R, typename T1, typename T2>
> > R min(T1 t1, T2 t2)
> > {
> > if (t1 < t2) return t1;
> > else return t2;
> > }
> >
> > if R is not explicitly specified in the function call then it is
> > deduced (as if it were specified with the putative "auto"
keyword.)
> >
> > This could also be extended to local variables-
> >
> > template<typename T1, typename T2, typename L>
> > void func(T1 t1, T2 t2)
> > {
> > const L& l = t1 + t2;
> > // ...
> > }
> >
> > One possible disadvantage with this syntax is that it is limited
to
> > template functions by definition, but this in fact could be an
> > advantage as it maintains the distinction between C-compatible
non-
> > template functions and C++ generic functions.
> > ...
> Note that this solution does not risk any conflict with any prior
> usage of the keyword auto. That is an advantage. It becomes a big
> advantage if at least one important smoking-gun counter-example is
> found regarding this innovative re-use of the existing keyword auto.
For me the major problem with "auto" is a consistency and pedagogical
issue. Although the "auto" keyword is not used in code, the auto
storage class is, and will continue to be, widely referred to in
documentation on the semantics of C++, so in a sense the overloaded
use of the keyword could cause problems (of course the only reason
that "auto" is unneeded in code is that auto is the default storage
class).
More fundamentally though, I find the consistency argument to be the
most compelling. The underlying problem is that the existing C++
language definition only specifies type deduction for function
arguments, and leaves out function return and local variable
contexts. So the obvious and consistent approach, IMO, to complete
the deduction machinery is to use the existing syntax and semantics
for argument deduction and simply extend it to the currently non-
deduced contexts of function return and local variables.
I think that having a separate syntax "template<typename T>" for
function argument deduction and "auto" for function return and local
variable deduction is inconsistent.
Moreover, the "auto" keyword doesn't provide the full matching
functionality of the type deduction that already exists for function
arguments.
e.g.
template<typename T1, typename T2, typename L>
void func(const T1& t1, const T2& t2)
{
const L& l = func2(t1, t2);
}
and an explicit name for the deduced type allows it to be referred to
elsewhere...
template<typename R, typename T1, typename T2, typename L>
complex<R> operator*(const complex<T1>& lhs, imaginary<T2> rhs)
{
L l1 = -(lhs.im * rhs); // L is deduced here
L l2 = lhs.re * rhs;
complex<L> ret;
ret.re = l1;
ret.im = l2;
return ret;
}
(in fact, how could this function be implemented using "auto" alone?)
,Brian Parker