Skip to content

P1391R4 Range constructor for std::string_view #3454

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Nov 21, 2019
Merged

P1391R4 Range constructor for std::string_view #3454

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
053e622
P1391R4 Range constructor for std::string_view
zygoloid Nov 14, 2019
de25e23
[string.view] Shorten stable name [string.view.deduction] -> [string.…
zygoloid Nov 16, 2019
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
52 changes: 52 additions & 0 deletions source/strings.tex
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -4020,6 +4020,8 @@
constexpr basic_string_view& operator=(const basic_string_view&) noexcept = default;
constexpr basic_string_view(const charT* str);
constexpr basic_string_view(const charT* str, size_type len);
template<class It, class End>
constexpr basic_string_view(It begin, End end);

// \ref{string.view.iterators}, iterator support
constexpr const_iterator begin() const noexcept;
Expand Down Expand Up @@ -4106,6 +4108,10 @@
const_pointer data_; // \expos
size_type size_; // \expos
};

// \ref{string.view.deduct}, deduction guide
template<class It, class End>
basic_string_view(It, End) -> basic_string_view<iter_value_t<It>>;
\end{codeblock}

\pnum
Expand Down Expand Up @@ -4174,6 +4180,36 @@
and initializing \tcode{size_} with \tcode{len}.
\end{itemdescr}

\indexlibraryctor{basic_string_view}%
\begin{itemdecl}
template<class It, class End>
constexpr basic_string_view(It begin, End end);
\end{itemdecl}

\begin{itemdescr}
\pnum
\constraints
\begin{itemize}
\item \tcode{It} satisfies \libconcept{contiguous_iterator}.
\item \tcode{End} satisfies \tcode{\libconcept{sized_sentinel_for}<It>}.
\item \tcode{is_same_v<iter_value_t<It>, charT>} is \tcode{true}.
\item \tcode{is_convertible_v<End, size_type>} is \tcode{false}.
\end{itemize}

\pnum
\expects
\begin{itemize}
\item \range{begin}{end} is a valid range.
\item \tcode{It} models \libconcept{contiguous_iterator}.
\item \tcode{End} models \tcode{\libconcept{sized_sentinel_for}<It>}.
\end{itemize}

\pnum
\effects
Initializes \tcode{data_} with \tcode{to_address(begin)} and
initializes \tcode{size_} with \tcode{end - begin}.
Copy link
Member

@jensmaurer jensmaurer Nov 16, 2019 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

size_t is of type size_type, but end-begin is of type ptrdiff_t. The conversion will "just work" even for the overflow case, but it's a bit odd.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Bug: end - begin has some signed-integer-like type (that isn't necessarily ptrdiff_t) but must be explicitly convertible to size_t per [iterator.concept.winc]/6. This needs to initialize size_ with static_cast<size_t>(end - begin).

As always, let-me-know-if-this-isn't-editorial-and-I'll-file-an-LWG-issue.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could simply say "direct-initializes size_t with end-begin", but that's a bit subtle.
@zygoloid , your call. (This also affects the similar text in the corresponding span changes.)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, my "bug" cry here was a bit of an overreaction - I (and apparently all of LWG) am still not used to non-integral difference types. Either "direct-initializes" or static_cast<size_t> would be great here, or we could clean it up post-merge via LWG issue. This certainly doesn't rise to the level of refusing to apply the proposal and sending it back to LWG, which "bug" would seem to imply.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems to me that this is just one instance of a systemic problem in the library wording. This phrasing "initializes x with y" is common, but underspecified (and formally meaningless) -- the library wording either needs to say what kind of initialization is performed, or specify an initializer (not an expression) with which to initialize. We should ask LWG to think about this; for each "initializes x with y" utterance, the reader should know what kind of initialization we mean.

Looking at random through the library wording, the first case I found: [queue.cons]/1:

Effects: Initializes c with cont.

The meaning of this depends on whether this is direct- or copy-initialization. (It's obscure, but if T is not Cpp17CopyInsertable into the container, it could be the case that one form of initialization works and the other does not, or that they both work and do different things.)

Another random sample: [partial.sum]/2:

Effects: For a non-empty range, the function creates an accumulator acc whose type is InputIterator's value type, initializes it with *first, and assigns the result to *result.

Again the difference between direct- and copy-initialization is observable here.

Perhaps the library should have blanket wording that when it says "initializes", it means by direct- or copy-initialization, and that it's unspecified which one you get (or something like that) -- and someone should go through all the instances and check if any of them mean something else (I doubt this is the only case that does). I'm not convinced that this particular instance of the problem needs to be dealt with while applying the motions.

@CaseyCarter Can you file an LWG issue, please?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've mailed lwgchair to ask for an issue.

\end{itemdescr}

\rSec3[string.view.iterators]{Iterator support}

\indexlibrarymember{const_iterator}{basic_string_view}%
Expand Down Expand Up @@ -4836,6 +4872,22 @@
Otherwise, returns \tcode{npos}.
\end{itemdescr}

\rSec2[string.view.deduct]{Deduction guide}

\begin{itemdecl}
template<class It, class End>
basic_string_view(It, End) -> basic_string_view<iter_value_t<It>>;
\end{itemdecl}

\begin{itemdescr}
\pnum
\constraints
\begin{itemize}
\item \tcode{It} satisfies \libconcept{contiguous_iterator}.
\item \tcode{End} satisfies \tcode{\libconcept{sized_sentinel_for}<It>}.
\end{itemize}
\end{itemdescr}

\rSec2[string.view.comparison]{Non-member comparison functions}

\pnum
Expand Down