Forwarding it to the list, since I sent if from a non-subscribed address.

On 11/12/21 22:26, Alejandro Colomar (man-pages) wrote:
> Hi Jens,
>
> On 11/7/21 22:29, Jens Maurer wrote:
>> On 07/11/2021 21.53, Alejandro Colomar (man-pages) wrote:
>>> Hi Jens,
>>>
>>> On 11/7/21 10:15, Jens Maurer wrote:
>>>> On 06/11/2021 22.31, Alejandro Colomar (man-pages) via Std-Proposals
>>>> wrote:
>>>>> However, VLA syntax for function parameters does not suffer from those
>>>>> issues: it is just syntactic sugar for pointer parameters.
>>>>
>>>> I'm not sure about that. My understanding is that sizeof(param) will
>>>> yield a runtime value in the body of the called function if "param" is
>>>> a VLA.
>>>
>>> Hmm, I thought I could hold the other proposal that I had in mind for
>>> just after this one, but maybe it's the other way around.
>>>
>>> Regarding what you said, the answer is "it depends". It depends if
>>> we're talking about single-dimension arrays or multi-dimensional arrays.
>>>
>>> There are 2 things going on there:
>>>
>>> - VLA syntax for pointer parameters
>>> - pointers to VLA
>>>
>>> In C, in the case of a single-dimension array in a function parameter,
>>> such as
>>>
>>> int foo(int n, int arr[n]);
>>>
>>> it is purely syntactic sugar, as `sizeof(arr)` == `sizeof(int*)` and
>>> *not* `sizeof(int) * n`.
>>
>> Good point; seems I was confused.
>>
>> In general, C99 offers a package of VLAs and variably-modified types
>> (the "subarrays" you were talking about), and any C++ proposal to
>> take some or all of that should clearly discuss the delineation of
>> the choice.
>
> Okay, the proposal is for C++ to add the VLA package _except_ for the
> stack allocation stuff, which is where the danger is.
>
> Proposed for inclusion to C++:
> - VLAs as function parameters
> - pointers to VLA
>
> Not proposed for inclusion to C++:
> - automatic (stack) VLA objects.
>
> The rationale for choosing ones and not the other is that the proposed
> ones don't suppose any danger, and instead simplify programming
> (especially C compatibility), while the stack allocated VLAs do.
>
>>
>> Also, it's not at all clear to me what level of support you'd get
>> for any proposal in that space. (My proposal for stack-allocated
>> VLAs was rejected a decade ago or so.)
>>
>> Jens
>>
>
> If I don't see any clear rejection, I'll start writing some draft soon.
> It may be especially difficult, since it's the first time I get
> involved in such a thing, and also since I'm expert in C but not in C++.
>
> Thanks,
> Alex
>