🚀 go-pugleaf

	The ARM, p. 176 says:

		The effect of calling nonstatic member function of a
		class C for something that is not an object of class C
		is undefined.

		For example,

			((X*)0)->f();
		
		is not guaratneed to work. ... Even for non-virtual
		functions, one should expect this trick to fail
		eventually because specialized C++ implementations might
		assume something about the contents of objects even when
		calling nonvirtual functions.  In particular, on might
		expect implementaions instrumented for debugging,
		interpretersm and implementations supporting dynamic
		loading to be sensitive to "housekeeping" information
		placed in the objects by the compiler.

		Natually, this trick would work only f() either checks
		its 'this' pointer before accessing any members or...
	
	IMHO, the ability to *depend upon* the (desired) fact that
	*calling* a non-virtual member-function with a nil pointer is
	*guaranteed* to be harmless seems worthwhile (and its addition
	to the language wouldn't break anything as far as I can tell).

	The alleged existence of "specialized C++ implementations" seems
	rather a "fringe" reason for saying that it's undefined; the
	standard could *make* it defined.

	The last paragraph is also vague; does it really mean "...this
	trick is *guaranteed* to work only if f() either checks its
	'this' pointer before accessing any members...?"

	The simple example where this is handly is a linked-list class
	where the objects are always dealt with via pointer.  The class,
	in its quest for robustness, could easily check its 'this'
	pointer before doing anything; consider also:

		void Link::DeleteAll() {
			for ( Link *p = this, *q; p; p = q ) {
				q = p->next;
				delete p;
			}
		}
	
	There's an initial test on 'this' so if I call DeleteAll() with
	a nil pointer, it should do nothing.  It would be nice to not
	have to check for nil in such cases; requiring it is prone to
	user error.

	To reiterate, all I would like is to guarantee that the *call*
	to a non-virtual member-function will succeed and that it's my
	responsibility to check for a non-nil 'this'.

	Comments?

-- 
	- Paul J. Lucas				University of Illinois	
	  AT&T Bell Laboratories		at Urbana-Champaign
	  Naperville, IL			pjl@cs.uiuc.edu