c++ - 如果 void 实际上被定义为 `struct void {};` 会破坏多少现有的 C++ 代码

Question

void是 C++ 类型系统中的一个奇怪的疣。它是一种无法完成的不完整类型，它有各种关于它可以使用的受限方式的神奇规则:

A type cv void is an incomplete type that cannot be completed; such a type has an empty set of values. It is used as the return type for functions that do not return a value. Any expression can be explicitly converted to type cv void ([expr.cast]). An expression of type cv void shall be used only as an expression statement, as an operand of a comma expression, as a second or third operand of ?: ([expr.cond]), as the operand of typeid, noexcept, or decltype, as the expression in a return statement for a function with the return type cv void, or as the operand of an explicit conversion to type cv void.

(N4778, [basic.fundamental] ¶9)

除了对所有这些奇怪的规则感到很痒之外，由于使用方式有限，它在编写模板时经常成为一个痛苦的特殊情况；大多数情况下，我们希望它的行为更像 std::monostate .

---

让我们想象一下，标准不是上面的引用，而是关于 void像

It's a type with definition equivalent to:

struct void {
    void()=default;
    template<typename T> explicit void(T &&) {}; // to allow cast to void
};

同时保留 void *魔术 - 可以为任何对象设置别名，数据指针必须在 void * 的往返过程中幸存下来.

这个:

• 应涵盖 void 的现有用例输入“正确”；
• 可能会允许删除通过标准传播的大量关于它的垃圾 - 例如。 [expr.cond] ¶2可能不需要，[stmt.return]将大大简化(同时仍然保留 return 没有表达式的“异常(exception)” void 和 void 函数的“流出”等效于 return; )；
• 应该仍然同样有效 - 现在到处都支持空类优化；
• 在现代 ABI 上本质上兼容，并且仍然可以由编译器在旧 ABI 上进行特殊处理。

除了兼容之外，这将提供:

• 构造、复制和移动这些空对象，消除模板中通常需要的特殊情况；
• void * 上的奖励指针算法, 操作为 char * ，这是一个常见的扩展，在操作二进制缓冲区时非常有用。

---

现在，除了 <type_traits> 的可能改变的返回值之外东西，这可能会破坏根据当前(C++ 17)规则格式良好的代码吗？

Answer 1

有一个建议，它是p0146: Regular Void

Presented below is a struct definition that is analogous to what is proposed for void in this paper. The actual definition is not a class type, but this serves as a fairly accurate approximation of what is proposed and how developers can think about void. What should be noticed is that this can be thought of as adding functionality to the existing void type, much like adding a special member function to any other existing type that didn't have it before, such as adding a move constructor to a previously non-copyable type. This comparison is not entirely analogous because void is currently no ordinary type, but it is a reasonable, informal description, with details covered later.

struct void {
  void() = default;
  void(const void&) = default;
  void& operator =(const void&) = default;

  template <class T>
  explicit constexpr void(T&&) noexcept {}
};

constexpr bool operator ==(void, void) noexcept { return true; }
constexpr bool operator !=(void, void) noexcept { return false; }
constexpr bool operator <(void, void) noexcept { return false; }
constexpr bool operator <=(void, void) noexcept { return true; }
constexpr bool operator >=(void, void) noexcept { return true; }
constexpr bool operator >(void, void) noexcept { return false; }

在Oulu June 2016 meeting Trip Report 中受到好评:

Regular void, a proposal to remove most instances of special-case treatment of void in the language, making it behave like any other type. The general idea enjoyed an increased level of support since its initial presentation two meetings ago, but some details were still contentious, most notably the ability to delete pointers of type void*. The author was encouraged to come back with a revised proposal, and perhaps an implementation to help rule out unexpected complications.

我和作者聊天，他确认基本上是在等待一个实现，一旦有实现他打算把提案带回来。

论文中广泛讨论了哪些变化和原因，它并不能作为一个整体进行引用，但解决的常见问题解答是:

• Doesn't This Proposal Introduce More Special-Casing for void?
• Why Isn't sizeof(void) Equal to 0?
• Does This Break std::enable_if?
• In Practice, Would This Break ABI Compatibility?
• Doesn't constexpr_if Make Branching for void Easier?
• Isn't It Illogical to Support some-operation for void?
• Doesn't This Remove the Notion of "No Result?"
• Isn't This a Change to the Meaning of void?