Re: 'Size hack for enumerated types

["Dan'l Miller" <optikos@verizon.net>]

On Tuesday, July 8, 2014 3:56:25 PM UTC-5, Randy Brukardt wrote:
> We've previously argued about a convention C_Plus_Plus or the like. We 
> decided not to go there for two reasons:
> (1) C_Plus_Plus is unspeakable ugly; C++ is bad syntax. We could get no 
> agreement on the name here.

  This is one of the very few areas where C++ was wiser than Ada:  C++'s analogous syntax is:  extern "C", where the string-quotes quarantine peculiar language names that would pollute the C++ grammar/parser.  I would suggest making Convention => "C" equivalent to Convention => C, then adding Convention => "C++".

> (2) We don't want to support convention C_Plus_Plus (or whatever it ends up 
> being called) on tagged types. Doing so insists that all tagged types are 
> represented as C++ does. That might be OK for GNAT (where the C++ compiler 
> is maintained in tandem), but it wouldn't work very well for any target 
> where the C++ compiler is from a separate organization. (I'm not interested 
> in chasing Microsoft on this, thank you.)

I agree.  There is no way that Ada should have Convention => "C++/CLI" for .NET boxed-type bytecode or Convention => "C++/CX" for boxed-type native machine-code.

> In addition other information is 
> needed which tends to vary between C++ implementations. We didn't think that 
> we could come up with a mechanism that was sufficiently abstract to allow 
> portability between implementations.

1000 pure Ada tagged types would need to conform to C++'s analogue (pointer to virtual-function table) just because 1 tagged type was annotated with Convention => "C++".  What might be too burdensome, is to go through every portion of the LRM to see where conforming to pointer to virtual-function table and non-virtual member-functions would change the Ada semantics for an Ada tagged type with Convention => "C++".

Your list is too short and not pessimistic enough.  There seem far more severe:

3) Name mangling.  Ada would need to conform to the highly-proprietary name-mangling conventions of encoding type information in very-lengthy function names.  In effect, this proprietarianism would seem to require the syntax of with Convention => "C++" to be something to the effect of with Convention => "Microsoft C++" or with Convention => "GNU C++" or with Convention => "Edison Design Group C++".

4) Exceptions.  Ada exceptions have no ability to have user-defined fields in a record that represents the exception.  As soon as full exception compatibility with C++ is admitted into Convention => "C++", then Ada exceptions would need to be expanded to have parity with the C++ expressivity of user-defined fields in exception structs.

> The ultimate decision was that we wouldn't define a C++ convention.

You make the decision sound so permanent, as if it cannot be divided & conquered by even partial attempts at Convention => "C++" that omit tagged types and exceptions.

> Implementations are supposed to have a dedicated convention for every 
> compiler they support. So if the C++ compiler does something different than 
> the C compiler, then the *implementation* should have a separate convention 
> for the C++ compiler. The language need not get involved, as portability 
> between implementations can't be guaranteed anyway.

I assume that you are saying here that portability is an impractical up-hill battle, not mathematically-provably impossible.