[00/10][RFC] Splitting the C and C++ concept of "complete type"

[Joseph Myers]

On Fri, 19 Oct 2018, Richard Sandiford wrote:

> Joseph Myers <joseph@codesourcery.com> writes:
> > On Thu, 18 Oct 2018, Richard Sandiford wrote:
> >> - Type introspection for things like parsing format strings
> >> 
> >>   It sounded like the type descriptors would be fixed-sized types,
> >>   a bit like a C version of std::type_info.
> >
> > It wasn't clear if people might also want to e.g. extract a list of all 
> > members of a structure type from such an object (which of course could 
> > either involve variable-sized data, or fixed-size data pointing to arrays, 
> > or something else along those lines).
> 
> OK.  But wouldn't that basically be a tree structure?  Or a flexible
> array if flattened?  It doesn't sound like it would need changes to

I don't know (but you mention flexible arrays, and initializers for 
flexible array members, where the size of the object ends up bigger than 
sizeof its type, are also a GNU extension).  Raise that question in the 
WG14 discussion; I'm not the right person to answer questions around 
everyone else's ideas for extensions to the C type system.  As far as I'm 
concerned, this is all a preliminary exploration of ideas that might or 
might not end up involving type system additions, and WG14 is a much 
better place for that than separate single-implementation discussions - 
the point should be to float and explore possible ideas in this space, and 
their benefits and disadvantages, rather than pushing too early for one 
particular approach.  And given how much C++ tends to use class-based 
interfaces where C uses built-in types (complex numbers, decimal floating 
point, ...), I definitely do not want to start from an assumption that the 
right interface or language concepts for this in C++ should look like 
those in C.

For me, thinking of SVE types as something like VLAs but passed by value 
seems a more natural model in C than having them sizeless - but if they 
are sizeless, that pushes them closer to other ideas for types that might 
also be sizeless (and if those other use cases are indeed best specified 
using sizeless types, that provides more justification for using sizeless 
types for SVE).

> > Is there something wrong with a model in C++ where these types have
> > some fixed small sizeof (which carries through to sizeof for
> > containing types), but where different ABIs are used for them, and
> > where much the same raw memory operations on them are disallowed as
> > would be disallowed for a class-based implementation?  (Whether
> > implemented entirely in the compiler or through some combination of
> > the compiler and class implementations in a header - though with the
> > latter you might still need some new language feature, albeit only for
> > use within the header rather than more generally.)
> 
> Having different ABIs would defeat the primary purpose of the extension,
> which is to provide access to the single-vector SVE ABI types in C and C++.

My suggestion is that the ABI for C++ would be different from that 
resulting for a class-based implementation using purely standard C++ (the 
difference being to make it the same as the SVE C API - as with the 
decimal floating-point classes).

-- 
Joseph S. Myers
joseph@codesourcery.com