为什么 std::sentinel_for 概念需要默认的可构造性？

Question

为什么新std::sentinel_for概念要求哨兵类型是default_initializable(via semiregular)？这是否排除了一大类有用的哨兵类型，其中默认构造没有任何意义？

例子：

//Iterate over a string until given character or '\0' is found
class char_sentinel
{
public:
    char_sentinel(char end) :
        end_character(end)
    { }

   friend bool operator==(const char* lhs, char_sentinel rhs)
   {
       return (*lhs == '\0') || (*lhs == rhs.end_character);
   }

   friend bool operator!=(const char* lhs, char_sentinel rhs) { ... }
   friend bool operator==(char_sentinel lhs, const char* rhs) { ... }
   friend bool operator!=(char_sentinel lhs, const char* rhs) { ... }

private:
    char end_character; 
};

我知道我可以添加一个默认构造函数来初始化，'\0'但是如果我认为这是对结构的滥用并且想要阻止这种情况怎么办？

Answer 1

虽然这并不是这个问题的严格重复，但我的答案在很大程度上仍然适用。

\n

《编程要素》关于类型行为方式的设计理念是它们应该如此regular，EoP 定义为：

\n

\n

T\xe2\x80\x99s 计算基础包括相等、赋值、析构函数、默认构造函数、复制构造函数、全排序（或默认全排序）和基础类型

\n

\n

我认为随着时间的推移，这一定义已被证明不是最有用的。对于许多算法而言，平等并不是必需的，因此semiregular. 但在许多情况下，甚至默认构造也是不必要的。

\n

虽然我们从P2325R3中的输入迭代器、输出迭代器和视图中删除了默认构造要求，但该论文没有触及（甚至讨论）哨兵。对于哨兵的争论在很大程度上是相同的——这不是一个重要的要求，算法也不需要它——但我们只是没有追求sentinel_for从要求弱化semiregular到仅仅要求copyable。我不确定我们是否有充分的理由避免这样做，除了不值得之外，因为无论如何，哨兵的编写频率都低于迭代器。

\n