This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of WP status.

3379. "safe" in several library names is misleading

Section: 24.2 [ranges.syn] Status: WP Submitter: Casey Carter Opened: 2020-01-21 Last modified: 2020-02-24

Priority: 1

View all other issues in [ranges.syn].

View all issues with WP status.

Discussion:

Various WG21 members have commented that the use of "safe" in the names safe_range, enable_safe_range, safe_iterator_t, and safe_subrange_t to mean "fairly unlikely to produce dangling iterators" is inappropriate. The term "safe" has very strong connotations in some application domains, and these names don't intend such connotations. We could avoid confusion by changing these names to avoid the use of "safe". The Ranges Illuminati has deemed "borrowed" to be more appropriate: it reflects the fact that such ranges often "borrow" iterators from an adapted range which allows them to not be lifetime-bound to the adapting range.

[2020-02-08 Issue Prioritization]

Priority to 1 after reflector discussion. This issue needs to be looked at by LEWG.

[2020-02-13, Prague]

Set to Immediate.

Proposed resolution:

This wording is relative to N4849.

  1. Replace all occurrences of safe_range, enable_safe_range, safe_iterator_t, and safe_subrange_t in the working draft with borrowed_range, enable_borrowed_range, borrowed_iterator_t, and borrowed_subrange_t.