Thanks everyone,

> Given that a large chunk of the problematic interfaces relate to text, SG16 seems
> like a good place to start asking for suggestions; copying the SG16 mailing list.
>I like Jonathan's suggestion of using a Google Doc to crowd source suggestions.

Tom, would you volunteer to organize that crowdsourcing?

I should have called out string_view as part of the "(et al.)", not just ranges/views.

Thanks,

Herb



From: SG23 <sg23-bounces_at_[hidden]> On Behalf Of Tom Honermann via SG23
Sent: Friday, October 13, 2023 1:10 PM
To: sg23_at_[hidden]; C++ Library Evolution Working Group <lib-ext_at_[hidden]>
Cc: Tom Honermann <tom_at_[hidden]>; SG16 <sg16_at_[hidden]>; Herb Sutter <herb.sutter_at_[hidden]>
Subject: Re: [isocpp-sg23] [isocpp-lib-ext] Span (et al.) for better bounds safety in the standard library

On 10/13/23 1:46 PM, Jonathan Wakely via SG23 wrote:

On Fri, 13 Oct 2023, 18:09 Herb Sutter via Lib-Ext, <lib-ext_at_[hidden]<mailto:lib-ext_at_[hidden]>> wrote:
Bounds safety is important, and our standard library APIs could use our own bounds-safe types more:


  * C++20 has std::span. [Party Popper Emoji (U+1F389)]


  * We are seeing more "bounds-checked std::span" modes: The C++ Core Guidelines Support Library (GSL) gsl::span, and GCC std::span (and other indexed access) checking<https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/include/std/span#L280> which will be enabled by the new GCC -fhardened<https://www.phoronix.com/news/GCC-fhardened-Hardening-Option>.


  * We are seeing user demand for std::span upgrades to standard library interfaces that currently use less-safe (raw-pointer, length) pairs: For example, here is a C++ Core Guidelines Issue<https://github.com/isocpp/CppCoreGuidelines/issues/2067> that asks the non-standard GSL to add more span APIs for standard functionality (in that case, to make up for basic_istream::read taking the error-prone (charT*, length), which really should be considered in the standard itself (e.g., shouldn't basic_istream::read at least have an overload that takes std::span<charT>? - similarly, what about s[n]printf?).


  * We look forward to adding contracts to the language, but those are complementary: Bounds-safe vocabulary types like std::span can cover cases preconditions can't, and vice versa.

Call to action: Are there any folks interested in writing on a paper to survey how/where to apply std::span (or other bounds-checkable ranges/views) broadly across the standard library to augment (even if we can't replace) APIs that currently take raw pointers and lengths?

I'm sure there would be strong support for this direction, so your time would be well spent. The heavy lift is for someone(s) to do the analysis and write the paper. Hence this request for that... any takers please?

I think we could collaborate here, with volunteers taking one of more subclauses to review. The combined analysis could be pulled together into a single paper, or we could do a paper per clause, as we did for the "mandating" papers.

If our wiki was safe for concurrent editing we could use that to gather the work, but maybe a Google doc would be better.

I agree.

Given that a large chunk of the problematic interfaces relate to text, SG16 seems like a good place to start asking for suggestions; copying the SG16 mailing list.

I like Jonathan's suggestion of using a Google Doc to crowd source suggestions.

Tom.

I would be very willing to review some library clauses but can't commit to the whole library.