$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
From: mfdylan (dylan_at_[hidden])
Date: 2002-02-19 01:00:55
--- In boost_at_y..., "Herb Sutter" <hsutter_at_a...> wrote:
> 
> Why not use "auto" here? It would avoid the typo too:
> 
>      template<class T, class S>
>      auto operator+(T &t, S &s)
>        { return t+s; }
> 
Because auto is an invalid storage class for a function - not even C 
allows this.
The proposals I've seen so far are for declaring/initialising local 
variables:
void foo()
{
   auto i = some_complex_function();
}
Which fits the current use of 'auto' as a storage class specifier, 
you are just omitting the type.
In C this means the variable is of type int.  In C++ it is currently 
not allowed to omit the type, but it would a reasonable enhancement 
to allow this such that the type is deduced from the value you are 
initialising the variable with (of course if you don't provide an 
initialiser, auto cannot work).  By extension you should also be able 
to use register for local variables, and static/extern for global 
vars:
static i = some_complex_function(); // no linkage
extern j(some_other_function()); // linkage within current namespace
void foo()
{
   auto k = some_complex_function();
   register l(some_other_function());
}
Note that you can't use it for members, but seeing as you can't 
initialise members upon declaration (other than static const int) 
this isn't an issue.
But if auto is to remain a storage class specifier you couldn't use 
it to declare functions.  So either auto's meaning needs to be 
explicitly changed, or you would need to use extern or static instead.
I doubt too many (if any) people still use 'auto' these days, but 
there is a potential danger in taking an already well defined keyword 
and changing it to mean something else.
There is also a signficant difference between ?: expression with 
operands of differing types and a function with multiple return 
points of different types.  ?: has only two types to attempt to 
reconcile, a function could have potentially infinite:
auto foo()
{
  if (rand())
    return "hello";  // const char[6]
  if (rand())
    return string(); // std::string
  if (rand())
    return typeid(0).name(); // const char*
  return tmpnam(0); // char*
}
Now all these are convertible to std::string, but could we really 
expect a compiler to figure this out?
I think it would be simpler to force all returns to use the same type 
if auto (or whatever) is used, otherwise it would be an error.
Dylan