Am Sonntag, den 31.01.2021, 20:46 +0100 schrieb Jens Gustedt via Liaison:
> Niall,
>
> on Sun, 31 Jan 2021 17:37:21 +0000 you (Niall Douglas via Liaison
> <liaison_at_lists.isocpp.org>) wrote:
>
> > Hopefully this made sense to you? Just to be clear, C under this
> > proposal
>
> this proposal?
>
> I know that we now have WG14 proposals for integrating lambdas into C
> :-)
>
> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2633.pdf
> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2634.pdf
> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2635.pdf
>
> but I wasn't aware that there is one for this:
>
> > would have most of C++ lambdas, but C's equivalent to
> > std::function<ret(args...)> would probably be something like
> > _Function(ret, args...). i.e. _Function would be a compiler built-in.
>
> already. I kept these things out for the moment, to ensure
> that WG14 first looks into everything that can be made here without
> ABI changes or additions.
>
> > I'm not a language person, nor a compiler person, but it seems to me
> > that dynamic runtime types do not easily produce bare metal execution
> > performance. I think indirection of dynamic information whilst
> > keeping the top level of the type system 100% static is a better
> > design approach.
>
> If you put this in this generality, it immediately sounds like a big
> deal.
>
> VLA (or VM types for that matter) only have the size (or sizes if
> multidimensional) as dynamic components and are not very difficult,
> neither to implement nor to use. C has them since a long time and they
> work well. And, contrary to the common belief and urban legends, they
> can be used to make programming with large arrays or even matrices
> much safer.
>
> I would hope that we could go here in a similar way to what I am
> trying to do with lambdas for WG14: take the simple and
> existing things that are well accomplished and mastered in one
> language and pull them into the other language to broaden the
> intersection. VM types here would be important to have for function
> interface compatibility between C and C++.

I agree,

I think a good first step would be simple ignoring the
length in the first level for extern C.

extern "C" void foo(int N, double x[N]);

becomes

extern "C" void foo(int N, double x[/* N */]);

for the C++ side. This would already remove most
of the pain for shared headers.


On the other hand, if C++ really does not want VM
types maybe we could define some mapping of C
into C++ types which could be used for extern "C".



Best,
Martin