🚀 go-pugleaf

I have to admit I'm becoming very discouraged by the amount of commentary
this subject is generating, without any corresponding understanding of
the issues as applied to object oriented programming.

I don't believe any compiler vendor is going to want to reduce the amount
of capability their C compilers have traditionally provided for 'bit-twiddling'

The real issue is what methods shall compilers writers be allowed to use
to implement inheritence.  This cannot have been an issue in the past, 
because C did not have inheritence.  Use a C structure, don't use inheritence,
and chances are about 99% that your C++ compiler will give you the same layout
as your C compiler.

But, given that a C++ compiler needs to implement inheritence, how shall
vendors be allowed to do so?  Should C++ compiler vendors all be forced
to follow the cfront model?  Or should vendors choose object models that
maximize efficiency for their target machines?

I, for one, believe there is a need to allow multiple object models.
Differing object models can allow significant trade offs between speed
and space.  Differing object models may be necessary to interface to other
OOPLs, or systems.  Newer object models can provide overall speed enhancements.

Therefore, I believe the issues are different in the face of inheritence
as opposed to a language without inheritence.  Please don't just keep
dragging out historical C examples of how you like to place bits.  That's
not the issue.  You'll still be able to do that.  The question is, what
should language users be allowed to do, and not do, via inheritence, and
what should compiler implementors be allowed to do, and not do, regards
inheritence?