Am Donnerstag, den 28.01.2021, 22:24 +0100 schrieb Jens Maurer:
> On 28/01/2021 18.45, Uecker, Martin via Liaison wrote:
> > Variably modified types have currently three problems
> > which are all fully in the scope of standards bodies:
>
> When reading "variably modified type" above, I'm assuming
> you talk about VLAs specifically.

VLAs and other types constructed from VLAs, such
as pointers to VLAs.

> > 3. And finally there is the problem that C++ does not
> > have them.
>
> Once upon a time, the C++ committee spent quite some effort
> on integrating VLAs.
>
> The history section in this paper
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0785r0.html
> is probably a good start.

Thanks.

> > 2. They are incompletely specified and not fully
> > integrated into C as types (e.g. one can not store a
> > varibaly-modified type in a struct).
>
> There was at least one attempt for this in C++, back in 2014:
> http://wg21.link/n3875
> (I dimly remember there being other approaches.)
>
> While everybody recognized the beauty of making VLAs
> first-class citizens of the type system that would
> happily compose via structs, the practicalities
> (including considering constructors) meant this
> didn't go anywhere.

In C we discussed something like:

struct foo {
  int n;
  float (*ap)[.n];
};

An alternative could a wide pointer type:

struct foo {
  float (*ap)[:];
};

If one does not want to introduce a general wide pointer
type, one could allow this only inside aggregates.
The bound would be stored in a hidden variable
and set automatically when the pointer is assigned.

This should be relatively simple to specify.

>
> As far as I understand, VLAs in C do not (and, practically
> speaking, cannot) affect static type checking, so we're
> looking for a solution that binds "array plus run-time length"
> sufficiently tightly to allow runtime checks.

Yes, we already have this, although compiler support
is not complete. And checks should be done at compile time
where the length is known from static analysis.

> In recent C++, there are many library-provided types / templates
> that offer this feature, both owning (std::string, std::vector)
> and non-owning (std::string_view, std::span).
> In C++20, we've gone to the next step and extended our
> algorithms library such that any algorithm that takes
> a range of values does so by taking a single "range"
> parameter, not two independent "start / end"
> (or, equivalently, "start / size") parameters.

Not sure how this could be translated to C.

Best,
Martin