I do not think containers complicate implementations, what does a few short
functions matter? If you think these methods are not good, you can not use
them.

P2278R3 <https://wg21.link/P2278R3#what-about-stdcbegin-and-stdcend> says
that changing std::cbegin and std::cend is not worthwhile, as there are
still deficiencies and may break existing code.

We have gotten off topic. I am just saying that these methods need to be
added to std::initializer_list (like everything else), not that the methods
themselves are good. Something that not everyone uses also needs to be
considered.

On Sun, Sep 4, 2022 at 7:16 PM Jiang An via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> I think they (those of containers) complicate implementations and look
> like stuffs in ancient-C++-era, despite being added in C++11. For
> containers and const views, the const-qualified begin/end are the
> expectedly presenting deep-constness.
>
> span (of a non-const element) is an example that separated cbegin/cend can
> be sometimes good. However, the corresponding non-member stuffs were not
> synchonized with non-const views in C++20, so the cbegin/cend were removed
> for **consistency**.
>
> Yours,
> Jiang An
>
>
>
> 发自我的小米
> 在 blacktea hamburger via Std-Proposals <std-proposals_at_[hidden]>，2022年9月4日
> 17:20写道：
>
> 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
>>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>