Path: utzoo!mnetor!tmsoft!torsqnt!hybrid!scifi!bywater!uunet!world!wmm
From: wmm@world.std.com (William M Miller)
Newsgroups: comp.lang.c++
Subject: Re: Null references
Message-ID: <1991Feb24.215757.19083@world.std.com>
Date: 24 Feb 91 21:57:57 GMT
References: <1991Feb13.224743.1123@lia> <70778@microsoft.UUCP>
Organization: The World Public Access UNIX, Brookline, MA
Lines: 55

jimad@microsoft.UUCP (Jim ADCOCK) writes:
> I agree with your desire that C++ support null references.  I asked for
> clarification on this issue on comp.std.c++ some time ago, and I think
> the issue has been discussed by the ansification committee, and I think
> the answer is that they decided *not* to explicitly support null references.
> Perhaps someone on the committee can confirm or deny this?

Let me clarify the organization of X3J16 before I answer this question
directly.  The committee has a number of informal subcommittees called
"working groups," dealing with issues like proposed extensions, libraries,
environments, etc.  These working groups have no authority beyond
recommending courses of action to the full committee; only the committee as
a whole can make decisions regarding what is and is not in the standard.

The issue of null references was discussed by the "core language" working
group, both via email and at the October meeting.  (The core language WG
deals with interpretation of the existing specification and with minor
modifications, while the extensions WG considers proposals for more major
changes.)  In the course of these discussions, the core language WG decided
1) that that current definition, embodied in E&S, does *not* allow null
references, and 2) not to recommend a change.

The relevant section of E&S is 8.4.3, page 153, where it says, "A variable
declared to be a T&, that is 'reference to type T' (section 8.2.2), must be
initialized by an object of type T or by an object that can be converted
into a T."  The result of applying unary * to a null pointer is not an
object, so it clearly cannot be used as an initializer for a reference.

The core language WG decided not to recommend a change to this policy for
several reasons, of which the two strongest were:

1) If the rule were relaxed to allow null references, code that currently
legitimately relies upon the language's guarantee that a reference is
connected to an object would no longer be safe.  Although it is true that
most implementations do not currently check for violations of the rule, it's
certainly reasonable to think that a debugging environment would do so and
find possible errors; if null references are permitted, no such checking
could be done.

2) References are conceptually aliases, not pointers.  Although they have
traditionally been implemented as pointers, there is no need for them to be;
a globally-optimizing compiler might well replace a number of references
with direct addressing.  If the nature of a reference is strictly a name for
an object, a "null reference" is an oxymoron.  It confuses the concept and
the implementation.

The full committee has not considered the issue specifically.  Since the
committee voted to accept the language as defined in the base document,
along with the minor changes introduced by E&S, action is only required for
a change to the definition; the core language WG's decision meant that no
such proposal was presented to the committee.

-- William M. Miller, Glockenspiel, Ltd.
   vice chair, X3J16
   wmm@world.std.com