Date: Fri, 13 Mar 2020 00:02:47 +0100
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
>
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
>
Received on 2020-03-12 18:05:48