Date: Sun, 4 Sep 2022 17:19:33 +0800
Can you explain more clearly why member cbegin/cend are not good ideas for
containers and const views? It seems that it is only true for std::span (so
they were removed).
Let initializer_list depending on reverse_iterator will not matter because
all entities in <iterator> except stream iterators are freestanding after
P1642R10 <https://wg21.link/P1642R10>.
On Sun, Sep 4, 2022 at 3:06 PM Jiang An via Std-Proposals <
std-proposals_at_[hidden]> wrote:
> Member data/size (and sometimes empty) are OK and may be necessary (or
> nice to have) for containers, but I believe for containers and const views
> (initializer_list, string_view, etc.), member cbegin/cend are not good
> ideas. And member rbegin and its friends are always bad IMO.
>
> I'm strong against adding rbegin etc. to initializer_list, this would add
> dependency on reverse_iterator.
>
> Yours,
> Jiang An
>
>
>
> 发自我的小米
> 在 blacktea hamburger via Std-Proposals <std-proposals_at_[hidden]>,2022年9月3日
> 21:26写道:
>
> How do you explain associative/unordered associative containers? Both
> their iterator/const_iterator member types are constant iterators, but
> they still provide cbegin/cend methods.
>
> And how do you explain rbegin/rend/empty, etc?
>
> On Sat, Sep 3, 2022 at 9:09 PM Jiang An via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>> I think if it's already known that il is initializer_list, one can just
>> write il.begin()/il.end(), as they return pointers to the const-qualified
>> element type.
>>
>> If the consistency between range types is desired, free function
>> templates or CPOs should be used since they handle built-in array types.
>>
>> Yours,
>> Jiang An
>>
>>
>>
>> 发自我的小米
>> 在 blacktea hamburger via Std-Proposals <std-proposals_at_[hidden]>,2022年9月3日
>> 20:53写道:
>>
>> But I think il.cbegin() is clearer.
>> They will also find that only il.begin()/il.end() works, which is weird.
>>
>> On Sat, Sep 3, 2022 at 8:40 PM Thiago Macieira via Std-Proposals <
>> std-proposals_at_[hidden]> wrote:
>>
>>> On Saturday, 3 September 2022 03:05:24 -03 blacktea hamburger via Std-
>>> Proposals wrote:
>>> > I do not believe that adding ranges eliminates the need to care about
>>> old
>>> > things. It's also impossible that no one will try il.cbegin() and get a
>>> > compile error.
>>>
>>> Yes, they will. At that point, they'll fix it to write:
>>>
>>> std::as_const(il).begin()
>>>
>>> --
>>> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>>> Software Architect - Intel DCAI Cloud Engineering
>>>
>>>
>>>
>>> --
>>> 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
>
containers and const views? It seems that it is only true for std::span (so
they were removed).
Let initializer_list depending on reverse_iterator will not matter because
all entities in <iterator> except stream iterators are freestanding after
P1642R10 <https://wg21.link/P1642R10>.
On Sun, Sep 4, 2022 at 3:06 PM Jiang An via Std-Proposals <
std-proposals_at_[hidden]> wrote:
> Member data/size (and sometimes empty) are OK and may be necessary (or
> nice to have) for containers, but I believe for containers and const views
> (initializer_list, string_view, etc.), member cbegin/cend are not good
> ideas. And member rbegin and its friends are always bad IMO.
>
> I'm strong against adding rbegin etc. to initializer_list, this would add
> dependency on reverse_iterator.
>
> Yours,
> Jiang An
>
>
>
> 发自我的小米
> 在 blacktea hamburger via Std-Proposals <std-proposals_at_[hidden]>,2022年9月3日
> 21:26写道:
>
> How do you explain associative/unordered associative containers? Both
> their iterator/const_iterator member types are constant iterators, but
> they still provide cbegin/cend methods.
>
> And how do you explain rbegin/rend/empty, etc?
>
> On Sat, Sep 3, 2022 at 9:09 PM Jiang An via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>> I think if it's already known that il is initializer_list, one can just
>> write il.begin()/il.end(), as they return pointers to the const-qualified
>> element type.
>>
>> If the consistency between range types is desired, free function
>> templates or CPOs should be used since they handle built-in array types.
>>
>> Yours,
>> Jiang An
>>
>>
>>
>> 发自我的小米
>> 在 blacktea hamburger via Std-Proposals <std-proposals_at_[hidden]>,2022年9月3日
>> 20:53写道:
>>
>> But I think il.cbegin() is clearer.
>> They will also find that only il.begin()/il.end() works, which is weird.
>>
>> On Sat, Sep 3, 2022 at 8:40 PM Thiago Macieira via Std-Proposals <
>> std-proposals_at_[hidden]> wrote:
>>
>>> On Saturday, 3 September 2022 03:05:24 -03 blacktea hamburger via Std-
>>> Proposals wrote:
>>> > I do not believe that adding ranges eliminates the need to care about
>>> old
>>> > things. It's also impossible that no one will try il.cbegin() and get a
>>> > compile error.
>>>
>>> Yes, they will. At that point, they'll fix it to write:
>>>
>>> std::as_const(il).begin()
>>>
>>> --
>>> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>>> Software Architect - Intel DCAI Cloud Engineering
>>>
>>>
>>>
>>> --
>>> 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 2022-09-04 09:20:00