C++Talk.NET

pongba@gmail.com · Guest

Hi, all:

Recently I've read through all the proposals about auto&decltype, and
there seems to be lots of interesting ideas there. Apparently auto
should be accepted into C++0x, as it surely did. But when it comes to
decltype, in particular, to "using 'decltype' to declare function
template return type", I have some doubts.

To me, the key question is:

Should 'auto' not be used as a return type indication that is decuced
from corresponding return statement in the function body? If not, why
on earth is that, 'cause I didn't see any demonstration or illumination
about that in N1705 which removed two sections used to exist in N1607
about "Functions with implicit return types" and "implicit templates".
The two ideas above, to me, are very good ones.

IMO, allowing simple forwarding functions to use auto as their return
type is the most obvious and convenient way, instead of the
heavy-weight " -> decltype(...)" solution which is no doubt a violation
of DRY(don't repeat yourself) principle and looks a little awkward and
weird, plus, I really don't know if there're multiple return
statements, which one should be choosed to declare the return type, to
wit:

template<typename T, typename U>
auto f(T t, U u) -> decltype(t*u) // or decltype(t+u)? either way
it's a distraction,
// not to mention the 3 or even
more return-statements cases!
{
if(...)return t*u;
return t+u;
}

Yeah, I know that in this case, all the return statement should have
the same type, so which one to choose doesn't really matter. But, hey,
it's not neat or elegant, and surely it's a distraction, yet there's
the DRY problem.

I wish I had the wit to figure out what's going on there, but I
couldn't, and I couldn't find any examples or counter-examples in the
proposals, instead I just saw the "functions with implicit return
types" suggestion been rejected by EWG, and I really don't know why. Of
course, the most tough obstacle is that it needs the function
definition to deduce the return type, but, considering that for simple
functions, such as plain forwardings, function is defined the first
time it's declared, it's just ok for these functions to use auto as
their return types. And there's a important fact that inlined template
functions exists widely, so forcing them to use "decltype(...)" to
declare the return type will introduce a considerable coding
effort(will it?), after all, who ever wants to see unnecessary
"decltype(...)"s all around the places?

So, after all, my suggestion is to restore the use of auto in
'automatic deducing of return type', it's natural, it's neat.

Had a function use 'auto' as its return type and not define itself
before the first place it's used, where it's definition is needed to
deduce the return type, it's ill-formed, diagnostics are necessary in
these cases in order to force the programmer to use the 'decltype(...)'
alternative to declare forward the fake 'return expression' or move the
function definition forward.

BTW. I suggest restoring the "implicit template" usage too, because,
you know, sometimes people just don't care about the 'T' or 'U' and
they don't necessarily use them, so forcing them to write
"template<....>" everytime is unfair, in that case, 'auto' is useful,
people can just focus on what they wanna do[ example:
void foo(auto a, auto b)
{
.. // I just use a and b to do things, and I don't really need the
type of a and b
}
-end example]

---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]

Michiel.Salters@tomtom.co · Guest

[email]pongba (AT) gmail (DOT) com[/email] wrote: