Date: Sun, 11 Sep 2022 22:47:26 +0800
So the standard library needs a cleanup, hopefully someone will push it
forward when the UFCS arrives.
On Sun, Sep 11, 2022 at 10:19 PM blacktea hamburger <
greenteahamburger_at_[hidden]> wrote:
> Thanks!
>
> On Tue, Sep 6, 2022 at 11:55 PM Brian Bi <bbi5291_at_[hidden]> wrote:
>
>> On Sat, Sep 3, 2022 at 9:26 AM blacktea hamburger via Std-Proposals <
>> std-proposals_at_[hidden]> wrote:
>>
>>> 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?
>>>
>>
>> It was a mistake to add .cbegin() and .cend() to standard library
>> containers, but deprecating them does not seem like a worthwhile tradeoff
>> at this point.
>>
>> Something that should be spelled std::as_const(x).begin() should not be
>> made into a member function for mere convenience. See
>> http://www.gotw.ca/gotw/084.htm .
>>
>> If you care that much about being able to write x.cbegin(), then you
>> should push for UFCS instead of adding mistakes to classes that don't have
>> them yet.
>>
>>
>>>
>>> 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
>>>
>>
>>
>> --
>> *Brian Bi*
>>
>
forward when the UFCS arrives.
On Sun, Sep 11, 2022 at 10:19 PM blacktea hamburger <
greenteahamburger_at_[hidden]> wrote:
> Thanks!
>
> On Tue, Sep 6, 2022 at 11:55 PM Brian Bi <bbi5291_at_[hidden]> wrote:
>
>> On Sat, Sep 3, 2022 at 9:26 AM blacktea hamburger via Std-Proposals <
>> std-proposals_at_[hidden]> wrote:
>>
>>> 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?
>>>
>>
>> It was a mistake to add .cbegin() and .cend() to standard library
>> containers, but deprecating them does not seem like a worthwhile tradeoff
>> at this point.
>>
>> Something that should be spelled std::as_const(x).begin() should not be
>> made into a member function for mere convenience. See
>> http://www.gotw.ca/gotw/084.htm .
>>
>> If you care that much about being able to write x.cbegin(), then you
>> should push for UFCS instead of adding mistakes to classes that don't have
>> them yet.
>>
>>
>>>
>>> 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
>>>
>>
>>
>> --
>> *Brian Bi*
>>
>
Received on 2022-09-11 14:47:54