Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!think.com!samsung!uunet!microsoft!jimad
From: jimad@microsoft.UUCP (Jim ADCOCK)
Newsgroups: comp.lang.c++
Subject: Re: Null references
Message-ID: <70873@microsoft.UUCP>
Date: 25 Feb 91 19:19:56 GMT
References: <1991Feb13.224743.1123@lia> <70778@microsoft.UUCP> <1991Feb24.215757.19083@world.std.com>
Reply-To: jimad@microsoft.UUCP (Jim ADCOCK)
Organization: Microsoft Corp., Redmond WA
Lines: 77

In article <1991Feb24.215757.19083@world.std.com> wmm@world.std.com (William M Miller) writes:
>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?
|
|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.

What you're saying then, is that use of null references will be an
unconstrained error -- programmers are not allowed to use them,
but compilers are not required to diagnose them.  This "unconstrained
error" situation comes up in a few places in the ANSI-C specs too, but
I think its generally a bad idea.  I believe that we should try to
keep to a situation where program examples fall into one of three
categories 1) strictly conforming 2) implementation dependent or 
3) constrained error.  Thus, I'd suggest a slight change from considering
null references "unconstrained errors" to "implementation dependent."

In practice, few programmers accept the idea that their program is
"illegal", yet that compilers accept and generate "correct" code for that
program without complaint.  Better then, to declare such programs as
"implementation dependent" so that we can warn programmer that such 
programs may not compile on some compiler some day in the future.

|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 basic problem I see with this approach is it denies people the
use of references to solve problems with pointers.  See the issues
coming from the ANSI-C numerical group regards restricted pointers
for one such example of people trying to solve problems with "C" pointers.

I propose then, that two problems of references need to be "fixed" so 
that they can be generally used to work around the problems with "C"
pointers.

1) A non-const, re-initable reference be introduced.  As Bjarne as pointed
out this would require the introduction of new syntax to represent 
reference re-initting -- introducing a new ":=" operator to represent
reference re-initting would be one such solution.  Then, the present
const references could continue to be const references that would allow
no possibility of re-initting.  You could even continue to make the
present const reference the default if you allowed the ~const syntax
to explicitly declare references that are re-assignable.

2) Allow overloadable operator dot so that reference syntax can be used
where, in fact, people are implementing smart references -- even though 
today they might mistakenly call them "smart pointers."