JTC1/SC22/WG21
N0720

Document Number: WG21/N0720
X3J16/95-0120
Date: 8 July 1995
Project: Programming Language C++
Reply to: Sean A. Corfield
sean@corf.demon.co.uk
operator void() revisited
Abstract
Some time ago the committee decided to make ill-formed the declaration of a
conversion function where the type is void (or cv-qualified void):
struct X {
operator void(); // ill-formed
};
The argument against this construct was based mainly on whether it should be
invoked for expression statements, where the value of the expression is
thrown away: implicitly converted to void. It was considered that such
'tricky' programming was undesirable.
Templates complicate the issue and operator void() could reasonably
arise from code like this:
template<typename T, typename U>
struct Func : public unary_function<T, U> {
operator result_type();
// ...
};
Func<int, void> vfi; // void f(int)
This paper proposes that operator void() be reinstated but remain uncallable.
Proposal
The declaration of operator void() should be well-formed but explicit
calls to it should be ill-formed. This allows template classes to be
written with arbitrary conversion operators dependent on template
parameters. No implicit conversions to void would invoke the operator.
Rationale
Disallowing the use of such operators mirrors the handling of
operator->() where 'illegal' declarations are allowed, but calls
are not.
WP changes
In 12.3.2 [class.conv.fct], paragraph 1, delete:
If conversion-type-id is void or cv-qualified void, the program is
ill-formed.
and add:
If conversion-type-id is void or cv-qualified void, the conversion
function is not considered for implicit conversions [Example: when
an expression statement implicitly converts to void to throw away
the result value] and an explicit call to such a conversion function
is ill-formed [Note: the intention is to allow declarations in
templates but not to allow calls to operator void()].