来自http://eel.is/c++draft/class.member.lookup#1：

在范围内搜索来自程序点PX的名称是对from的单个搜索，除非是类或类模板的范围，在这种情况下，以下步骤定义搜索结果。NXNPXT

[注1：只有当N是转换函数ID或单次搜索什么也没找到时，结果才会有所不同。——尾注]

我很难理解 Note。似乎来自类范围的“单一搜索”会在命名空间范围内找到前面的声明，因为命名空间范围包含类范围。但是，正如我们所知，如果名称也被声明为非依赖基类的成员，则基类成员优先于命名空间成员。注 1似乎与此相矛盾，因为它基本上是在说“如果N不是转换函数 ID，那么您可以只进行正常的单次搜索，并且只有当您找不到任何内容时，才使用本节中的过程”。但是单次搜索会通过找到命名空间范围声明而成功，并且类成员查找会产生不同的结果。

我的理解错误在哪里？

<spanstream>将在 C++23 中首次亮相（参见cppreference）。根据提案，它们是带有std::span基于缓冲区的字符串流。

我的问题是：

• 是否与旧的（或在 C++ 98 中已弃用）std::spanstream有一些等效的用途？std::strstreamstrstream
• 在 C++ 23 完全发布后使用它们有什么好处？

请看这个例子

GCCbase在 Clang 提示错误诊断时打印。在当前草案中，相关规则是这样定义的：
[class.virtual#2]

如果在类 B 中声明了一个虚成员函数 F，并且在从 B 派生（直接或间接）的类 D 中，成员函数 G 的声明对应于 ([basic.scope.scope]) F 的声明，忽略尾随的要求子句，然后 G 覆盖 F。

同时，定义两个对应的声明的规则是这样定义的：
[basic.scope#scope-3]

如果两个声明（重新）引入相同的名称，都声明构造函数，或都声明析构函数，则两个声明对应，除非

• [...]
• each 声明一个函数或函数模板，除非

• 两者都声明具有相同参数类型列表的函数，等效 ([temp.over.link]) 尾随要求子句（如果有，除非 [temp.friend] 中指定），并且如果两者都是非静态成员, 相同的 cv-qualifiers (如果有的话) 和 ref-qualifiers (如果两者都有的话), 或者

在此示例中，#1并且#2具有相同的参数类型列表，#1具有一个引用限定符而#2没有，因此可以忽略后一个限制，因此，对于这两个声明，我们可以说它们是对应的。因此，#2覆盖#1声明为虚函数。因此，如果我们遵守当前的草案，我们可以说 GCC 和 Clang 的结果都是错误的。

但是，在c++20标准中，如何确定派生类中声明的声明覆盖基类中声明的虚函数的限制是：
[class.virtual#2]

如果虚成员函数 vf 在类 Base 和 Derived 类中声明，直接或间接从 Base 派生，则具有相同名称、参数类型列表 ([dcl.fct])、cv 限定的成员函数 vf , 和 ref-qualifier (或没有相同)作为 Base​::​vf 被声明，然后 Derived​::​vf 覆盖 Base​::​vf。

很明显，现在的规则已经改变了它原来的含义。这是新规则的缺陷吗？或者，只是为了改变需求而进行的人为设计？

我已经阅读了lazy_split_view添加的最新草稿。

但后来，我意识到它split_view被重命名为lazy_split_view，并且split_view被更新了。

libstdc++最近也通过使用GCC Trunk版本https://godbolt.org/z/9qG5T9n5h实现了这一点

我在这里有一个简单的天真程序，显示了两个视图的用法，但我看不出它们的区别：

输出：

直到我注意到std::span<const char>两个视图使用 as 时的差异。

在第一个std::views::split：

编译器接受我的代码。

在第二个中：std::views::lazy_split

抛出编译错误。

我知道这两者之间会有差异，但我不能轻易发现它们。这是 C++20 中的缺陷报告还是 C++23 中的新功能（有更改），或两者兼而有之？

C++23 将引入if consteval. 这将在哪里使用，它与 有何不同constexpr if？

从 C++23 开始，views 不再需要是default_constructible. views::filter对于和等范围适配器views::transform，它们的默认构造函数被重新定义为：

并且由于p2325r3中的默认构造函数ref_view已被删除，这表明应用于 lvalue的范围适配器不再是：rangestd::vector default_constructible

只有当范围适配器被应用到default_constructible views 中时，例如std::string_viewor views::iota(0)，返回的视图才可以是default_constructible：

但是对于这些情况，即使可行，我也真的想不出制作这些views的用例。default_constructible如果我们view默认构造a，就意味着我们构造了一个empty view，对empty s应用范围适配器显然是没有意义view的：

在我看来，C++20 中范围适配器的默认构造函数只是为了满足view，由于view不再需要default_constructible在 C++23 中，因此这些适配器的默认构造函数不需要存在。

为什么这些范围适配器的默认构造函数在 C++23 中没有被删除，而是变成了约束函数？真的有需要它的情况default_constructible吗？这背后的考虑是什么？

关于提案“更简单的隐式移动”（P2266R1），我不确定我是否正确理解了这个新的“符合移动条件”的东西。

如果不正确，请更正以下几点：
[ LIVE ]

1. std::forward对于完美转发收到的右值 ref 变为可选

变成

2. std::move成为本地创建的右值引用的可选

变成

3. std::moveoptionaly 变成parenthesis only为本地创建的东西返回一个右值引用。

变成

注意： (3) : clang trunk 在我发布此内容时警告返回本地堆栈地址。

2021-08-02 更新

https://github.com/cplusplus/papers/issues/968#issuecomment-915353127

https://isocpp.org/files/papers/P1018R13.html#P2266r1

投票结果：✅共识。但是，反对票来自实施者，并带来了相关的新信息。这个话题需要重新讨论，并且可能无法通过全体投票。

有时我必须解析具有各种编码的文本文件，我想知道即将推出的标准是否会为此带来一些工具，因为我对当前的解决方案不太满意。我什至不确定这是否是正确的方法，但是我定义了一个仿函数模板来从流中提取一个字符：

我ReadChar用来实现解析功能：

丑陋的部分是static_cast我需要与 char 文字进行比较的时候。

然后我使用parse这个丑陋的样板代码：

现在，这个解决方案有一些怪癖（不能在 中直接使用字符串文字parse）我的问题是是否有解决这个问题的替代方法，可能使用我忽略的现有或即将推出的标准设施。

反射 TS - 此处描述的 C++ 功能： https ://en.cppreference.com/w/cpp/keyword/reflexpr

我正在寻找有关此功能的任何信息。

我有这张表描述编译器支持： https ://en.cppreference.com/w/cpp/compiler_support

但我没有看到这个功能是计划好的，或者这个功能的名称不同？

哪个 C++ 版本将支持此功能？

我在哪里可以找到有关此主题的任何教程/信息？

我正在阅读为 C++23 提议的库更改列表，我对std::out_ptrand std::inout_ptr（他们的_t兄弟姐妹）很好奇。据我了解，它们是智能指针与原始指针兼容的某种包装器，但我还没有设法理解它们。也许这里有人熟悉该提案，或者可能会给出不太类似 ISO 的解释或示例？