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.

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]g> 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