[C++-sig] Retiring "ref", etc.

[David Abrahams]

From: "joel de guzman" <djowel at gmx.co.uk>


> > there's a small fly in that ointment: while it might make some sense to
> > allow a null reference, it makes no sense at all to think of a null
object.
> > I'm not talking about None, here: I mean a null PyObject*.
>
> object, as a name, seems to be perfect and sensible. I am not
> quite sure about the implications but isn't it possible to make
> the semantics of a null PyObject* be like a None object?

Possible, but not desirable.

> > Unfortunately, it's sometimes important to be able to manage a
> > possibly-null PyObject*,
>
> I've written run-time libraries for dynamically typed interpreters
before.
> The core data type I always use is a C++ reference counted object
> called 'value' [ object is a better name ]. In my implementation, there
> is no null (in the C/C++ sense)-object. There's always an object being
> pointed to. There is however a nil object, akin to python-None. To
> keep the implementation from having to construct/allocate destruct/
> deallocate nil-objects, I keep only one that goes into scope at the
> very beginning and out of scope at the very end. All nil objects share
> this singleton.

The problem, unfortunately, is that Python will hand us a null PyObject*
whenever it wants to signal failure. Common idioms are:

    // get the attribute if it exists
    reference<> x(PyObject_GetAttrString(y.get(), "some_attribute"));
    if (!x) // if not found
    {
        PyErr_Clear(); // clear the exception
        ...            // do something else
    }
    else
    {
        // use x
    }

If I keep the (IMO wise) policy of avoiding manual reference-counting in
favor of taking immediate possesion with some kind of smart pointer there
will be times when initializing the smart pointer with 0 will be
unavoidable. I don't much care about how that zero-ness is represented
inside the smart pointer (we could make it point at some singleton), but
there needs to be a representation for zero.

> > so it appears that reference<> must stay alive in some form or other.
>
> IMHO, I don't see how a null reference makes more sense than
> having a null object.

I agree :(. So maybe reference<> is the wrong name, as I suggested earlier.
I'm still open to suggestions.

> If you ask me, I'm more concerned about
> having both a null-reference and a reference to None with different
> behavior.

There's nothing special about None, so in that respect there's nothing to
worry about.

-Dave