(This has been raised before, I'm trying to find out what the status
or non-status of the feature is.)

Currently, the following constitutes an error, which makes certain
template constructs more inconvenient:

void fn1() {}
void fn2() { return fn1(); }

Bjarne Stroustrup a while ago posted to the effect that he had formally
submitted a request to add this usage to the standard, and apparently
it got denied (below I've included the relevant portion of the Dec 2 1996
final draft).

Can someone confirm what status this feature has, i.e. that it
definitely got denied by the committee and we have no hope of seeing
it added?

[stmt.return] 6.6.3 The return statement
[...]
2 A return statement without an expression can be used only in
functions that do not return a value, that is, a function with the
return value type void, a constructor (12.1), or a destructor (12.4).
A return statement with an expression can be used only in functions
returning a value; the value of the expression is returned to the
caller of the function. If required, the expression is implicitly
converted to the return type of the function in which it appears.
A return statement can involve the construction and copy of a temporary
object (12.2).

Flowing off the end of a function is equivalent to a return with no value;
this results in undefined behavior in a value-returning function.


> Subject:      Returning void
> From:         bs@research.att.com
> Date:         1996/02/25
> Message-Id:   <199602250134.SAA02280@ncar.ucar.EDU>
> Newsgroups:   comp.std.c++
> [More Headers]
>
> Paul D. DeRocco <pderocco@ix.netcom.com> writes:
>
>  > The C++ standard doesn't allow a return statement with an expression to
>  > be used in a function whose return type is void.
>  >
>  > I suggest that it should be legal to return a void expression from a
>  > function whose type is void. Why? It can be useful in templates.
>  > Consider the following:
>  >
>  >     template <class T, class R> class Functor {
>  >     public:
>  >         R& operator()() { return (obj.*mem)(); }
>  >         Functor(T& o, R& (T::*m)()): obj(o), mem(m) {}
>  >     private:
>  >         T& obj;
>  >         R& (T::*mem)();
>  >     }
>  >
>  > This defines a functor containing a pointer to an object to be operated
>  > on, and a pointer to a member function defined for that object. It
>  > should work for any member function that takes no arguments and returns
>  > a result. Unfortunately, it won't work for a member function that
>  > returns void. If return were modified as described above, this function
>  > template would work for member functions that return void as well.
>
> I have written a note to the committee formally proposing this. The reason
> stated was roughly the one above. In addition - and for the same reason -
> I proposed to allow an expression of type void to be used as the argument
> of a function taking no argument.
>
> There is no guarantee that the committee will accept this or even that the
> committee will consider it (though clearly I think the committee ought to).
>         - Bjarne
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Paul Bossi wrote:
>
> (This has been raised before, I'm trying to find out what the status
> or non-status of the feature is.)
>
> Currently, the following constitutes an error, which makes certain
> template constructs more inconvenient:
>
> void fn1() {}
> void fn2() { return fn1(); }
>
> Bjarne Stroustrup a while ago posted to the effect that he had formally
> submitted a request to add this usage to the standard, and apparently
> it got denied (below I've included the relevant portion of the Dec 2 1996
> final draft).

The Dec 2 draft is not final. It is a "Committee Draft" in ISO
terminology. If approved by the ISO voting process which is still in
progress, it will become a "Draft International Standard", still
subject to minor amendments. ISO National Bodies typically submit
comments about changes they wish or require as part of the voting
process. (I don't expect anyone who isn't required to do so to be
able to keep straight all of this administrivia. I just want to be
clear that the CD is not "final", although few changes are permitted
at this point without beginning the CD process again.)

> Can someone confirm what status this feature has, i.e. that it
> definitely got denied by the committee and we have no hope of seeing
> it added?

The issue is still open, and will probably be decided at the July
meeting.
It is recommended to be accepted in the set of comments from at least
one National Body. My impression at the last meeting was that it is
likely to be accepted.

--
Steve Clamage, stephen.clamage@eng.sun.com
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]