🚀 go-pugleaf

In article <1992Aug21.044448.8282@sunb10.cs.uiuc.edu> pjl@sparc10.cs.uiuc.edu (Paul Lucas) writes:
|	If programmers elected not to check the this pointer, then the
|	program, if a member is accessed via a null-this, would most
|	likely crash or at least be undefined; this is _exactly_ the
|	way language is defined now; hence, for programmers who ignore
|	it, the (errant) behavior of their programs is unchanged.
|
|	*****************************************************************
|	Hence, adding my proposal changes nothing for those who ignore
|	it.
|	*****************************************************************
|
|	Again, all I want is the *call* to succeed; after that, I'm on
|	my own.

The call already doesn't necessarily succeed in the virtual case.
The call already doesn't necessarily succeed in the null-this-from-a-ref case.
You are asking for support for a special case where a non-virtual member
function is invoked via a null pointer.  Asking for this singular special
case seems awfully non-orthogonal to me.  If you were to insist on this,
then it should work for null-refs and for virtual functions....

|	Perhaps [with regard to users checking null tests]; but I think
|	that one of the _themes_ of programming in C++ is to eliminate
|	tedium and errors introduced thereby: virtual functions
|	eliminate switch statements missing a case; exception-handling
|	will eliminate having to check the return value from new to see
|	if it failed, etc.
|
|	I see my (modest) proposal in the same light.

In the early days of Objective-C method invocation on a null pointer was
defined to be a no-op.  The result was intended to save programmers from
having to handle special cases.  In practice the result was that it took
about a week to track down each case where some method was invoked on
a null pointer -- because the result of such a mistake was a null pointer
-- resulting in another no-op method call, resulting in a null pointer --
resulting in another no-op call.  Fortunately, we had access to source and
quickly patched the method dispatch routine so that invoking a method via
a null pointer resulted instead in an assert.  Then bugs were caught quickly.

Therefore I suggest rather than allowing method invocation on null pointers
what one really needs is a good way to always assert on such "mistakes."
Allowing overloadable operator dot is one step in this direction.  Further,
defining null ptr invocations as being illegal *allows* quality compiler
implementations the option of inserting runtime checks on such illegalities
during debug mode.  Better yet would be if C++ supported better ways to specify
class invarients checking on method dispatch and return.