C++ Ranges transform视图迭代器为何不支持operator->操作符

问题复现与标准符合性 #

对应场景下的编译报错属于完全符合C++标准的预期行为，相关复现代码如下：

void transform_view( )
{
    struct Z { int a; };

    std::ranges::single_view view { Z { 99 } };

    auto transform_view { std::ranges::views::transform( view, []( auto const& z ){ return Z { z.a + 10 }; } ) };

    // 该行代码无法编译：迭代器未定义operator->
    // auto transform_view_first_value { transform_view.begin( )->a };
}

根据C++标准对std::ranges::transform_view迭代器的定义（章节24.7.6.3），本身就未要求实现operator->接口，不属于库实现的缺陷。

Ranges迭代器能力的通用规则 #

Ranges体系下的迭代器接口要求完全和其所建模的迭代器概念绑定，不存在“所有迭代器必须支持operator->”的统一要求：

• 传统STL中需要实现operator->的迭代器，本质是解引用后返回元素的稳定左值引用，此时operator->的语义是返回指向该左值的指针，不存在语义歧义。
• Ranges覆盖了大量惰性生成、每次解引用构造临时对象的视图场景，这类迭代器解引用返回的是纯右值/临时对象，不存在可指向的长期有效左值，强行实现operator->会直接引入悬垂指针风险。

transform_view的具体设计逻辑 #

transform_view的迭代器不实现operator->的核心原因是语义本身不成立：

• 视图的映射函数返回值和底层元素不存在左值关联，每次解引用迭代器时才会执行映射逻辑生成新的临时对象，该临时对象在当前完整表达式结束后就会析构，不存在稳定内存地址可供返回。
• 如果强行实现operator->，只能返回指向临时对象的指针，一旦用户跨表达式保存该指针，就会触发未定义行为，完全违背Ranges的类型安全设计原则。
• 按照迭代器概念的约束，只有当迭代器的reference关联类型是真实的左值引用时，才会被要求实现operator->；如果reference是值类型、右值引用类型，operator->本身就没有可落地的合法语义。

合法替代实现 #

该场景下访问元素成员不需要依赖operator->，直接对解引用返回的临时对象执行成员访问即可，临时对象在当前完整表达式内保持有效，无悬垂风险：

// 合法写法，无未定义行为
auto first_a = transform_view.begin()->a;

内容的提问来源于stack exchange，提问作者goneskiing