Date: Sun, 11 Sep 2022 22:19:45 +0800
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*
>
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:20:12