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

[David Abrahams]

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

> I see. So the next thing that pops in my mind is to make the
> null an internal implementation detail and instead expose
> a pseudo *error_object* that abstracts the signaling of an
> error condition. That way, there is only one interface where
> an object with a null /representation/ will act practically as an
> error object.

Sorry, I can't make heads nor tails of the above paragraph.

> > 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.
>
> Other than signalling an error condition, what else is the role
> of this special case?

Python is written in 'C'. What roles can a null PyObject* have?
Default-constructed smart pointers need to have a value.
Python tuples start out initially empty (not full of None) when you
construct them.
...and so forth.

> I reckon that the answer to this question
> will ultimately lead us to >> what really is this thing which is
> represented by a zero <<. I strongly feel that it is just a matter
> of category.

Not sure what the implications of assigning it a category it might be,
either.

> > I agree :(. So maybe reference<> is the wrong name, as I suggested
earlier.
> > I'm still open to suggestions.
>
> I'm inclined to suggest having just an ^object^ that covers the
> special error case if the only difference between an ^object^
> and a ^reference^ (or ptr), is the signalling of the error condition.

I'm against this approach. The current reference<> throws by default if you
pass null to the constructor, and that default behavior is used in 99% of
cases. It works with Python synergistically: when Python returns via an
error it becomes an exception in the user's code.

That really is the behavior users want from their object type in most
cases. Also, it's a basic principle of reliable software engineering that
"invalid" object states are best avoided. It's much cleaner to know that if
I get passed an "object", it's valid, and not some "error state". Otherwise
code is either full of checks to see whether we're holding the error
object, or (more likely) it simply ignores errors because they're too much
trouble.

What I'm heading toward is a two-level interface: a smart pointer type
("reference<>", or pick a better name) which can be null, for low-level
interfacing with Python, and a higher-level type, "object", which can never
be null, and which provides a nice Python-objec-like interface.

-Dave