🚀 go-pugleaf

I am reposting the following response from ekrell to my question about
the rules regarding incomplete types.  Some people may be interested
in seeing how AT&T cfront 2.0 responds.

-----------------------------------------------------------------------------
>From ekrell%ulysses@research.att.com Sat Jan 21 13:06:09 1989

This is AT&T cfront 2.0:

x.C:
  1	class first_class;
  2
  3	class second_class {
  4	public:
  5		first_class some_function ();
  6	};
  7
  8	another_function ()
  9	{
 10		second_class second_class_object;
 11	
 12		second_class_object.some_function ();
 13	}

nCC -c x.C:

"x.C", line 12: error: first_class  undefined, size not known
"x.C", line 10: warning:  second_class_object used but not set

So there appears to be at least one bug in G++ (1.32.0) which gives
no errors for the above program fragment.  I have also checked that
the same thing is true even if the incomplete type name (first_class)
is used as a formal parameter type in the declaration of "some_function".

What I don't understand about the AT&T approach is why the errors are
issued only for "indirect" uses of the incompletely-defined entity,
i.e. why is there an error issued for a call to "some_function" and
yet there is no error issued for the actual definition of "some_function".
This seems rather fishy to me, but then I can see how some contorted
logic might be used to justify this.  I'd just like to see somebody
else state the reasoning for this approach.  Bjarne?  You Listening? :-)

// 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