Re: [boost] Re: Most needed/desired features in C++

From: Greg Colvin (gcolvin_at_[hidden])
Date: 2002-02-19 01:58:54

And of course, having gotten rid of implicit int, we don't need a
keyword at all:

      template<class T, class S>
      operator+(T &t, S &s) {   
        v = t+s;                // type of v is implicit 
        return v;               // return type is implicit
      }

Or even easier:

      operator+(t, s) {         // type of t and s are implicit
        v = t+s;                // type of v is implicit 
        return v;               // return type is implicit
      }
 

From: "mfdylan" <dylan_at_[hidden]>
> --- 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
> 
> 
> 
> Info: http://www.boost.org  Send unsubscribe requests to: <mailto:boost-unsubscribe_at_[hidden]> 
> 
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 
> 
> 
>