🚀 go-pugleaf

I'm not sure if this is a bug in G++ (1.32.0), a bug in the language
definition itself, or just a strange feature, but here goes.  Consider
the following code:

////////////////////////////////////////////////////////////////////////////
class first_class;

class second_class {
public:
	first_class some_function ();
}

another_function ()
{
	second_class second_class_object;

	second_class_object.some_function ();
}
////////////////////////////////////////////////////////////////////////////

No errors are generated when G++ 1.32.0 compiles the code above.

I believe that this is wrong for two reasons.

1)	After the call to some_function() a type "first_class"
	object should be returned on the stack.  Unfortunately,
	the compiler cannot possibly know how big such objects are
	and thus it cannot possibly pop the returned object off
	of the stack correctly.

2)	The "first_class" object returned from the call to some_function()
	may also need to have it's associated destructor called
	before the space it is occupying can be reclaimed.
	Unfortunately, the compiler cannot possibly know (at the
	point of the call to some_function()) whether or not the full
	definition of the class "first_class" has a destructor or not.
	Thus, it cannot possibly know whether or not it should
	generate a call to the destructor at that point.

I believe that a proper response to the above code would have been to issue
an error message at the point at which the function "some_function" is
first declared.  The message should say that the return type for the function
(i.e "first_class") is not yet fully defined.

Any comments?  Could somebody please see what AT&T cfront does with this.

// Ron Guilmette  -  MCC  -  Experimental (parallel) Systems Kit Project
// 3500 West Balcones Center Drive,  Austin, TX  78759  -  (512)338-3740
// ARPA: rfg@mcc.com
// UUCP: {ihnp4,seismo,ucb-vax,gatech}!cs.utexas.edu!pp!rfg