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

[Richard Sandiford <richard dot sandiford at arm dot com>]

Hi Martin,

Thanks for the reply.

"Uecker, Martin" <Martin.Uecker@med.uni-goettingen.de> writes:
> Hi Richard,
>
> as Joseph pointed out, there are some related discussions
> on the WG14 reflector. How a about moving the discussion
> there?

The idea was to get a feel for what would be acceptable to GCC
maintainers.  When Arm presented an extension of P0214 to support SVE
at the last C++ committee meeting, using this sizeless type extension
as a possible way of providing the underlying vector types, the feeling
seemed to be that it wouldn't be considered unless it had already been
proven in compilers.

> I find your approach very interesting and that it already
> comes with an implementation is of course very useful
>
> But I don't really understand the reasons why this is not based
> on (2). These types are not "sizeless" at all, their size
> just isn't known at compile time. So to me this seems to me
> a misnomer.
>
> In fact, to me these types *do* in fact seem very similar
> to VLAs as VLAs are also complete types which also do no
> have a known size at compile time.
>
> That arrays decay to pointers doesn't mean that we
> couldn't have similar vectors types which don't decay.
> This is hardly a fundamental problem.

I think it is for some poople though.  If the vectors don't decay to
pointers, they're moe akin to a VLA wrapped in a structure rather than
a stand-alone VLA.  There is a GNU extension for that, e.g.:

  int
  f (int n)
  {
    struct s {
      int x[n];
    } foo;
    return sizeof (foo.x);
  }

But even though clang supports VLAs (of course), it rejects the
above with:

  error: fields must have a constant size: 'variable length array in structure' extension will never be supported

This gives a strong impression that wrapping a VLA type like this
is a bridge too far for some :-)  The message makes it clear that's
a case of "don't even bother asking".

The vector tuple types would be very similar to this if modelled as VLAs.

> I also don't understand the problem about the array
> size. If I understand this correctly, the size is somehow
> known at run-time and implicitly passed along with the
> values. So these new types do not need to have a
> size expression (as in your proposal). 

The problem isn't so much that the size is only known at runtime,
but that the size isn't necessarily invariant, and the size of an
object doesn't carry the size information with it.

This means you can't tell what size a given object is, even at runtime.
All you can tell is what size the object would be if you created it
from scratch.  E.g.:

  svint8_t *ptr;  // pointer to variable-length vector type

  void thread1 (void)
  {
    svint8_t local;
    *ptr = &local;
    ...run for a long time...
  }

  void thread2 (void)
  {
    ... sizeof (*ptr); ...;
  }

If thread1 and thread2 have different vector lengths, thread2 has no way
of knowing what size *ptr is.

Of course, thread2 can't validly use *ptr if it has wider vectors than
thread1, but if we resort to saying "undefined behavior" for the above,
then it becomes difficult to define when the size actually is defined.
It's simpler not to make it measurable via sizeof at all.  (And that's
a much less invasive change to the language.)

> Assignment, the possibility to return the type from
> functions, and something like __sizeless_structs would
> make sense for VLAs too.
>
> So creating a new category "variable-length types" for 
> both VLAs and variably-length vector types seems do make
> much more sense to me. As I see it, this would be mainly
> a change in terminology and not so much of the underlying
> approach.

But do you have any feel for whether this would ever be acceptable
in C++?  One of the main requirements for this was that it needs
to work in both C and C++, with the same ABI representation.
I thought VLAs were added to an early draft of C++14 and then
removed before it was published.  They weren't added back for C++17,
and I'd seen other proposals about classes having a "sizeof field"
instead (i.e. the type would carry the size information with it,
which we don't want).  So the prospects didn't look good.

Thanks,
Richard