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

### 3379. "`safe`" in several library names is misleading

Section: 26.2 [ranges.syn] Status: C++20 Submitter: Casey Carter Opened: 2020-01-21 Last modified: 2021-02-25

Priority: 1

View other active issues in [ranges.syn].

View all other issues in [ranges.syn].

View all issues with C++20 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`.