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.

3351. ranges::enable_safe_range should not be constrained

Section: 24.2 [ranges.syn] Status: WP Submitter: Jonathan Wakely Opened: 2019-12-05 Last modified: 2020-02-24

Priority: 0

View all other issues in [ranges.syn].

View all issues with WP status.

Discussion:

Currently ranges::enable_safe_range is constrained with ranges::range, which not only forces the compiler to do unnecessary satisfaction checking when it's used, but also creates a tricky dependency cycle (ranges::range depends on ranges::begin which depends on ranges::enable_safe_range which depends on ranges::range).

The only place the variable template is expected to be used is in the ranges::safe_range concept, which already checks range<T> before using enable_safe_range<T> anyway.

The constraint serves no purpose and should be removed.

[2019-12-12 Issue Prioritization]

Status to Tentatively Ready and priority to 0 after eight positive votes on the reflector.

Proposed resolution:

This wording is relative to N4842.

  1. Modify 24.2 [ranges.syn] as indicated:

    [Drafting note: The definition in 24.4.2 [range.range] p7 is already unconstrained, which contradicts the synopsis.]

    […]
    // 24.4.2 [range.range], ranges
    template<class T>
    concept range = see below;
    
    template<rangeclass T>
    inline constexpr bool enable_safe_range = false;
    
    template<class T>
    concept safe_range = see below;
    […]