Date: Sat, 30 Nov 2019 19:35:33 +0200
On Sat, 30 Nov 2019 at 18:55, Lyberta via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> John McFarlane via Std-Proposals:
> > Sanitizing user input sounds like something that is best served by explicit
> > logic. I certainly don't think that UI is any concern of containers.
>
> Explicit logic such as
>
> if (i >= std::size(whatever))
> {
> throw std::out_of_range{"Invalid index."};
> }
>
> How is that better than calling at()?
I can't find either innocent or non-innocent users who would find it
better. Some of the non-innocent
ones would simply choose to write .at(), by mere 'fiat' of "this does
the same thing, I KNOW WHAT I
AM DOING, out of my way please". There's no shortage of such
programmers, based on my
anecdotal findings. The innocent ones might write at() as well,
because, as I said, "this punts
the decision to folks who know better". The arguments of at()
hopefully wishfully not existing
doesn't stand scrutiny, as far as I've observed.
> And without it developers will have write their own version of std::at()
> anyway. I have my own versions of std::insert() and std::emplace()
> already. By users I meant users of the library.
That goes back to "How many? How many times, as in, do they change
their decision to write that,
over time? Is that a sufficiently significant problem that a standard
API should solve it"?
Again, I have little sympathy for the above questions, I'm just sayin'
that they will be asked
in a committee discussion. (And if they wouldn't be asked, I might(*)
question whether the committee
is doing its job. :D) (*) Which I won't, because I will make sure that
the committee will ask those
questions.
<std-proposals_at_[hidden]> wrote:
>
> John McFarlane via Std-Proposals:
> > Sanitizing user input sounds like something that is best served by explicit
> > logic. I certainly don't think that UI is any concern of containers.
>
> Explicit logic such as
>
> if (i >= std::size(whatever))
> {
> throw std::out_of_range{"Invalid index."};
> }
>
> How is that better than calling at()?
I can't find either innocent or non-innocent users who would find it
better. Some of the non-innocent
ones would simply choose to write .at(), by mere 'fiat' of "this does
the same thing, I KNOW WHAT I
AM DOING, out of my way please". There's no shortage of such
programmers, based on my
anecdotal findings. The innocent ones might write at() as well,
because, as I said, "this punts
the decision to folks who know better". The arguments of at()
hopefully wishfully not existing
doesn't stand scrutiny, as far as I've observed.
> And without it developers will have write their own version of std::at()
> anyway. I have my own versions of std::insert() and std::emplace()
> already. By users I meant users of the library.
That goes back to "How many? How many times, as in, do they change
their decision to write that,
over time? Is that a sufficiently significant problem that a standard
API should solve it"?
Again, I have little sympathy for the above questions, I'm just sayin'
that they will be asked
in a committee discussion. (And if they wouldn't be asked, I might(*)
question whether the committee
is doing its job. :D) (*) Which I won't, because I will make sure that
the committee will ask those
questions.
Received on 2019-11-30 11:38:07