Boost logo

Boost :

From: brianjparker (brianjparker_at_[hidden])
Date: 2002-02-19 09:20:18

--- In boost_at_y..., Emily Winch <emily_at_b...> wrote:

> > that people with a legitimate use for 'auto' don't throw all
> > over-board and focus on quick-and-easy solutions. If
finally 'auto' as a
> > keyword is the only and best option to solve the problems, OK,
but it
> > shouldn't be added just because it's easy.
> Agreed. At the moment, I'm convinced that it is the best (not the
> option, and that the need for it overrides the concern over
providing bad or
> inexperienced programmers more things to make a mess with. I can
argue the
> first of those things, but the second is only an opinion with
nothing to
> back it up. (Other than a gut
> feeling that if people are going to write code and not explain what
it does,
> they'll
> do it anyway, auto or not).

I agree that the functionality of "auto" as discussed in this thread
is essential- it fills a major hole in the current C++ type deduction
machinery. (The fact that one can't even write a simple function like
max(T1 t1, T2 t2) directly in the current language is evidence of

I also agree that a function with a deduced return type would need to
have its implementation visible to the compiler, which is the case
anyway for current template implementations. I think that the issue
with "export" is a red herring- as you say, if future implementations
of export do not require the source to be visible then one can simply
disallow the use of auto with export.

Earlier comments in this thread raised the issue of what to do with a
function with multiple return paths; I think that it is essential
that the compiler deduce this case to the common convertible case
(analogously to ?:). This is needed to allow the obvious, direct
implementation of many functions e.g.

template<typename T1, typename T2>
auto min(T1 t1, T2 t2)
   if (t1 < t2) return t1;
   else return t2;
(albeit, in this example one could simply use ?: in the

Previous comments have questioned whether this "auto" facility is
needed if a typeof keyword was available. Whilst a typeof keyword may
indeed provide a superset of the functionality of auto, it is IMO
overkill for the most common situation of function return and local
variable type deduction in that it provides a full reflection
capability (i.e. returns a type) where all that is needed is type
inference (the exact type need not be known). Also, as discussed
previously, it would require error-prone redundant duplication of
type expressions. (In fact, I question whether, for real-world code,
a typeof facility would even be required given an auto facility).

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.

Another possible disadvantage for the local variable deduction case
is that if there were many deduced local variables then the function
template argument list could become unwieldy. I don't think that this
would be a problem in practice, but if it was then an alternative
syntax (suggested by David Abrahams who attributed it to Andrew
Koenig), such as-

template<typename T1, typename T2>
void func(T1 t1, T2 t2)
   template<typename L>
   const L& l = t1 + t2;
   // ...

could be used. (Personally, I don't think the additional syntax and
changes to the grammar would be worth it).

Anyway, this is really just a different syntactic suggestion for
the "auto" proposal that IMO fits more neatly and intuitively with
the existing C++ grammar.

,Brian Parker

Boost list run by bdawes at, gregod at, cpdaniel at, john at