On 30/01/2021 17:47, Uecker, Martin wrote:

>> I think the chances of C++ adopting VLAs are indistinguishable from
>> zero. But C supporting a subset of C++ ranges (specifically, contiguous
>> ranges), well that I can see plenty of WG21 support for, in principle at
>> least.
>
> the only type I am missing in C is a wide function type similar
> to std::function to call callable objects from other languages.
> (In theory, function pointers in C could be wide but ABIs can
> not changed.)

That is indeed useful. However if C were to adopt C++ lambdas, that's
95% of you there (plus lambdas solve an absolute ton of other itches in
C). The only thing remaining would be some facility to erase a given
capturing lambda instance into a corresponding non-lambda invocable
instance with a call signature compatible with existing C ABIs, and
you'd have what you want.

(Note the hand wave here that C lambdas would be but one form possible
of "unknown invocable all I know of which is that I can invoke it with
this specific C callable")

> The wide pointers for arrays would be syntactic sugar
> around variably-modified type, so nothing we need urgently.

Well that depends on how you'd implement them I think. I, like most C++
folk, dislike intensely any notion of runtime-varying type or size of
type. I would be fairly certain that anything C adopts which involves
runtime-varying type or size will never be supported in C++.

And that might be fine from a C perspective, but I think you can get
wide pointers for arrays etc exclusively using static types, or bounded
reference types. And if you can, I think you should.

> I am not sure what C++ does here we could adapt, you mention
> span or ranges. But what would be the corresponding
> C++ type for the following dynamic multi-dimensional array?
>
> double (*ten)[z][y[x] = malloc(sizeof *ten);

That would be mdspan (https://wg21.link/p0009).

mdspan isn't in the standard yet. It's harder than it looks in fact,
because there _may_ be a ton of stuff you'd really like the compiler to
optimise aggressively for, if only you could provide enough hints and/or
appropriate layout for say SIMD or GPU offload to be guaranteed chosen
by the compiler, for some given mdspan configuration. People are still
batting around non-mdspan, mdspan++, --mdspan, and other variations on
the design.

My personal suspicion is that we'll end up just choosing mdspan, but
caution is appropriate given that WG21 previously did a suboptimal job
with std::valarray, which is nowadays considered in the same category as
std::vector<bool> - well intentioned, useful, but not fully thought through.

Whilst I don't propose that C should implement Ranges a la C++, Python
or Rust, I do think a bare minimum builtin primitive on top of which
Ranges can be safely constructed would be fabulous. By which I mean that
Sewell et al type proof of correctness would be possble. This is not
something C++ currently can do, because the language knows nothing about
string_view, span, mdspan etc, and so we cannot really prove that a
program using these are correct.

(Just so I am 100% being clear here, I'd really like C++ via C to gain
the ability to spot when a string_view is used after its string's
lifetime has ended. If C implemented a primitive on top of which C++
could built lifetime checks such as those, we all win, and your sudo
buffer overflow never again happens in newly written code)

Niall