Le dim. 19 avr. 2020 11 h 31, Tony V E via Std-Proposals <
std-proposals_at_[hidden]> a écrit :

> Or you could stop using at.
>

Weird argument. Good thing span has operator[], or we would have to stop
using it.

Sent from my BlackBerry 10 smartphone.
> Original Message
> From: Roman Babinicz via Std-Proposals
> Sent: Sunday, April 19, 2020 7:18 AM
> To: JeanHeyd Meneide via Std-Proposals
> Reply To: std-proposals_at_[hidden]
> Cc: Roman Babinicz
> Subject: Re: [std-proposals] std::span
>
>
> I really do not like how it is NOT a drop in replacement for other
> containers (or const-reference since it is not-owning of course).
>
> Getting a [const-reference] to container and taking element from them is
> very common use case for me, and I often use .at() .
>
> This means c++20's std::span is not usable for me and I have to write
> own span.
>
> On 15/04/2020 05:22, JeanHeyd Meneide via Std-Proposals wrote:
> > Dear Mario,
> >
> > On Tue, Apr 14, 2020 at 9:52 PM Mario Charest via Std-Proposals
> > <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]>>
> > wrote:
> >
> > ...
> > What is the rational for std::span not having an at() fonction, like
> > most other contiguous container.
> >
> >
> > Because at() is a mistake for string view and all other cheap view
> > types; that we made the mistake with string_view is unfortunate.
> >
> > There are two problems with at() as a member function, today.
> >
> > The first is it's design. at() should not be a member function, and
> > should never have been implemented as one. at() should have been a free
> > function defined something like this:
> >
> > template <typename Whatever>
> > decltype(auto) at (Whatever& __whatever, typename
> > ::std::remove_cvref_t<Whatever>::difference_type __index)
> > noexcept(noexcept( ::std::data(__whatever))) {
> > if (std::size(__whatever) >= __index)
> > throw ::std::out_of_range("out of range");
> > return *(::std::data(__whatever) + __index);
> > }
> >
> > This:
> >
> > - Is not a member function so is decoupled from everything and does
> > not require exceptions baked into something that can live without it
> > - Makes it easy to pick between "I want checking" and "I don't want
> > checking", explicitly, by the user
> > - Works for every contiguous view/container, whether it exists in
> > the standard or not
> >
> > It scales better, works nicer, and can be isolated with other such
> > "checking" functions. Very nice.
> >
> > The second is the contention that comes from C++'s exceptions
> > burden. One of the biggest problems (and biggest benefits) of at() is
> > that it throws an exception on out-of-bounds. This is cute and nice and
> > wonderful, save for that in C++ this means bringing in a dependency on
> > using "throw", and throwing a standard exception. All standard
> > exceptions defined in the standard library -- out_of_range(), for
> > example -- have a constructor that takes a std::string, because the
> > string view technology wasn't there yet.
> >
> > This WOULD cost every person using the span header enormously, and makes
> > presenting these things in Freestanding-As-We-Would-Like-It -- with no
> > exceptions and other things -- difficult. std::string also transitively
> > does things like bring in iostreams and other header garbage. Many
> > implementations have spent plenty of man-hours trying to increase
> > forward declarations and other tricks to save on compile time for doing
> > #include <string>. If <span> had to do this, we would tank people's
> > compile times for just an exception and a string. Again.
> >
> > Right now, <span> is a nice header that does not add an extra method for
> > bounds checking that drags in an exceptions dependency and a strings
> > dependency, and it would be well to keep this way for all eternity.
> >
> > That being said, maybe an at() free function should be proposed and
> > dumped into some safety header for standard C++.
> >
> --
> 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
>