C++ Logo

STD-PROPOSALS

Advanced search

Subject: Re: [std-proposals] Fixing C-style arrays
From: Gašper Ažman (gasper.azman_at_[hidden])
Date: 2020-03-12 18:08:18


"the latter camp" is trying to tell you that what you are proposing has
significant and non-trivial cost which c++ might be unwise to pay.
Listening and addressing these legitimate concerns is in your best interest
if your proposal is to be taken seriously in the slightest. Not listening
to concerns is what gets proposals killed.

G

On Thu, Mar 12, 2020, 23:03 Maciej Cencora via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> FYI I am in the camp "fix the problem by fixing the root cause", not in
> the camp "fix the problem by introducing another way of doing it, and not
> really fixing the original problem".
>
> I am not interested in any feedback from the latter camp.
>
> pt., 13 mar 2020 o 00:00 Garrett May via Std-Proposals <
> std-proposals_at_[hidden]> napisał(a):
>
>> I'm confused by this. Your end goal is to be able to have a stack-based
>> array that supports assignments, comparisons, and passing & returning from
>> functions; yet the alternative that the standard library provides -
>> std::array - does precisely that. The reason it exists is exactly because
>> of your concerns, which other people have had in the past.
>>
>> Due to the fact that C++ is mostly built on top of C, it makes sense to
>> try and maintain compatibility with it, especially when code requires
>> calling functions from C's standard library. Deprecating core
>> functionalities of C could lead to code breaking in many places.
>>
>> I encourage using std::array, as its job serves your purpose. To ignore
>> it due to:
>> - preventing correct deduction of constructors due to brace-ellision; and
>> - slow compilation time due to template float
>> seems unwise; I would suggest actually to address these problems instead,
>> as that in my opinion seems to be the real problem at heart here.
>>
>> On Thu, 12 Mar 2020, 10:33 pm Maciej Cencora via Std-Proposals, <
>> std-proposals_at_[hidden]> wrote:
>>
>>> Yes, I am fully aware of std::array but it does not fix the C-style
>>> arrays, it just provides another solution for stack-based const size arrays
>>> (and one that does not always work as expected due to brace-elision
>>> preventing correct deduction of constructors being called for each element).
>>>
>>> I am proposing to fix C-style arrays. I don't want yet another const
>>> size array container (and especially the one that slows compilation time
>>> due to template bloat).
>>>
>>>
>>> czw., 12 mar 2020 o 23:06 Ryan Nicholl via Std-Proposals <
>>> std-proposals_at_[hidden]> napisał(a):
>>>
>>>> We have std::array for this purpose, so that compatibility with C is
>>>> not broken.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> -------- Original Message --------
>>>> On Mar 12, 2020, 17:40, Maciej Cencora via Std-Proposals <
>>>> std-proposals_at_[hidden]> wrote:
>>>>
>>>>
>>>> Hi,
>>>>
>>>> I propose to deprecate in C++23:
>>>> 1) mixed pointer and array comparisons:
>>>> int a[2]; int b[2];
>>>> a == &b[0];
>>>>
>>>> 2) array decl in func parameters:
>>>> void foo(int a[2]);
>>>>
>>>> In order to make C-style arrays behave like other aggregate types in
>>>> C++26 or later (supported assignments, comparisons, passing and returning
>>>> from functions)
>>>>
>>>> Regards,
>>>> Maciej
>>>> --
>>>> Std-Proposals mailing list
>>>> Std-Proposals_at_[hidden]
>>>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>>>
>>>> --
>>> Std-Proposals mailing list
>>> Std-Proposals_at_[hidden]
>>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>>
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>



STD-PROPOSALS list run by herb.sutter at gmail.com

Standard Proposals Archives on Google Groups