Re: [boost] auto (was Most needed/desired features in C++)

From: Fernando Cacciola (fcacciola_at_[hidden])
Date: 2002-02-19 14:56:15

----- Original Message -----
From: "David Abrahams" <david.abrahams_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Tuesday, February 19, 2002 4:26 PM
Subject: Re: [boost] auto (was Most needed/desired features in C++)

>
> ----- Original Message -----
> From: "Fernando Cacciola" <fcacciola_at_[hidden]>
>
> >
> >
> > Just as I wear the hat of 'don't use implicit conversions', I would wear
> the
> > hat of "don't use auto return types" if they were allowed.
> >
> > I do however, support the 'auto' for variable declaration because there
is
> > not a conversion involved even though the type is implicit.
>
> You could use "explicit auto" to suppress implicit conversions yet permit
> return type deduction.
>
> -Dave
>
But, IMO, this would be of little help most of the times.
In most cases when return type deduction is handy, conversions are required
nevertheless. I'm not against the conversions but against implicit
conversions to implicit types. Is the 'double' implicit that worries me.

Also, I'm not against return type deduction schemes, I'm against
unexpressive deduction schemes.

For local variable declarations, there's not too much harm in letting 'a' be
of type 'auto'. For return types, 'auto' is too unexpressive to me.

I'm sure we can think of a type deduction scheme powerful enough to keep
return types totally expressed, but easy to write.
That is, what we really want is a way to express:

template<...>
type_deduction<whatever_1>::type foo(whatever_2);

We are thinking of hiding 'type_deduction<whatever_1>::type' with the nice
word 'auto', or something like that, but then, we are hidden "the type"
instead of "the way to express that type".  They might appear the same but
they aren't:  If I write: auto foo(), I'm not only typing less, but also
expressing less, and that's not a good idea.

I think that we should focus on extensions to achieve better flexibility to
create type expressions. typeof() is a good start, but it isn't enough.

Allowing return types to use information contained in parameters, as has
been suggested, is perhaps a good improvement.

Fernando Cacciola
Sierra s.r.l.
fcacciola_at_[hidden]
www.gosierra.com