C++ Logo

std-proposals

Advanced search

Re: std::span

From: Ville Voutilainen <ville.voutilainen_at_[hidden]>
Date: Mon, 20 Apr 2020 12:38:50 +0300
On Mon, 20 Apr 2020 at 12:33, Lyberta via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> Ville Voutilainen:> That "unsafe code" will compile anyway, you've just made it
> > inconvenient to write - we need to use a compare() function
> > as opposed to just using operator==.
> Unsafe code must be inconvenient to write.

..so as to make perfectly safe code inconvenient to write, too.

> For that reason reinterpret_cast is named that way. The fact that
> std::set<std::string_view> and std::map<std::string_view, T> compile is a bug.

In java, that's perhaps a correct statement.

> > Also, by that definition,
> > references and pointers are similarly unsafe
> Sure, have you ever seen std::set<char*> or std::map<char*, T>? At least it is common knowledge that raw pointers are unsafe and
> shouldn't be used in most code.

Right. Ban those uses. Programmers, after all, need hand-holding from
people who have no idea what they're talking
about.

> > A major use case for span and string_view is parsing - get a sub-range
> > to something, compare it like it's a whole
> > range.
> Sure, if you want deep comparison, use explicit code. For pointers you'd do *i == *j. Dereference is explicit.

The data can change at any time. Do not allow such comparisons. In
fact, do not allow the comparisons of anything,
the data can change if non-const references to it have ever escaped anywhere.

This sort of thinking is a disease.

Received on 2020-04-20 04:42:00