Re: Most needed/desired features in C++

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 
caution
> > 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 
only)
> 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 
this.)

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

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