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.
safe
" in several library names is misleadingSection: 25.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.
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
.