P1881 中基于 C++ 模块的时期与潜在的基于 #pragma 的时期

Question

在P1881 提案中，提出了 C++ 代码的时期（在模块级别）的概念。此类功能可以允许在模块级别自定义 C++ 语法和 C++ 行为，而不必破坏向后兼容性。 More elaborate motivation is given in the proposal。

提案中的隐式转换示例

版本 1：没有 epoch，一切都可以正常编译

module ParticleMovement;

export void move(Particle&, float x, float y);

void moveExample()
{
    Particle p{};
    move(p, 3.42, 2.49);    // OK
}

版本 2：epoch 2023（假设禁用隐式转换），代码格式错误：

epoch 2023;                 // Module-level switch
module ParticleMovement;

export void move(Particle&, float x, float y);

void moveExample()
{
    Particle p{};

    move(p, 3.42, 2.49);    // Compilation error

    move(p, 3.42f, 2.49f);  // OK, no implicit conversions
}

这绝对是一个有趣的提议，与简单地指定编译开关-std=c++XXX 有很大不同。

但是，我想知道：

• 在 P1881 中，epoch 被定义为模块级开关。除了方便之外，还有什么理由必须在模块级别上吗？为什么不是翻译单元级别？
• 因此，这种行为能否通过#pragma 无缝实现，提供编译器支持，或者与基于模块的提案相比会引入严重的技术困难（从实现或使用的角度来看）？

说，大致上：

#pragma epoch 2023;                 

export void move(Particle&, float x, float y);

void moveExample()
{
    Particle p{};

    move(p, 3.42, 2.49);    // Compilation error

    move(p, 3.42f, 2.49f);  // OK, no implicit conversions
}

我已阅读the proposed mechanism，它针对基于模块的实现；但是，我不明白为什么必须是模块。

---

也相关：a lightning talk at CppCon 2019 of Vittorio Romeo, the author of P1881 proposal

Answer 1

在P1881 中，epoch 被定义为模块级开关。除了方便之外，还有什么理由必须在模块级别上吗？为什么不是翻译单元级别？

理论上，epoch-declarations 可以出现在任何级别，包括块范围甚至库范围。我为提案的第一次修订选择了模块，因为它们足够小，可以允许大型项目从一个时期优雅地迁移到另一个时期，但也足够大，不会在同一个源文件中出现多个时期。

在贝尔法斯特，有人建议模块分区可能是更好的选择，因为它们允许单个模块逐渐迁移到更新的时代。

---

这种行为能否通过#pragma 无缝实现，提供编译器支持，或者与基于模块的提案相比会引入严重的技术困难（从实现或使用的角度来看）？

原则上，我认为这是可能的。不管选择#pragmas 还是模块级声明，我相信编译器供应商仍然需要执行大量工作来实现像epoch 这样的东西（但我相信这是值得的）。

---

我不明白为什么它必须是模块。

确实没有。在 P1881 中，我不仅尝试发明一种允许改变语法含义的机制，而且还尝试设想一种能够很好地适应 C++ 生态系统并促进良好工程实践的机制。

我相信与模块级声明相比，块范围声明或#pragma 有更多的滥用机会。我还认为，将 epoch 与模块绑定可以帮助开发人员在模块化现有代码库的同时考虑 epoch 迁移。

总的来说，该提案仍处于早期阶段，所有这些设计决策都可能发生变化。我们总是感谢您的反馈和想法——作者的电子邮件可以在论文中找到。