On Sat, 27 Apr 2019 at 13:28, Henri Sivonen <hsivonen_at_[hidden]> wrote:
> Having types that enforce Unicode validity can be very useful when the
> language has good mechanisms for encapsulating the enforcement and for
> clearly marking cases where for performance reasons the responsibility
> of upholding the invariance is transferred from the type
> implementation to the programmer. This kind of thing requires broad
> vision and buy-in from the standard library.
>
> Considering that the committee has recently
> * Added std::u8string without UTF-8 validity enforcement
> * Added std::optional in such a form that the most ergonomic way of
> extracting the value, operator*(), is unchecked
> * Added std::span in a form that, relative to gsl::span, removes
> safety checks from the most ergonomic way of indexing into the span,
> operator[]()
> what reason is there to believe that validity-enforcing Unicode types
> could make it through the committee?

Both std::optional and std::span provide 'safe' ways for extracting
and indexing.
The fact that the most-ergonomic way of performing those operations is
zero-overhead
rather than 'safe' should be of no surprise to anyone. The reason to
'believe' that
validity-enforcing Unicode types could make it through the committee depends
on the rationale for such types, not on strawman arguments about
things completely
unrelated to the success of proposals for such types.