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

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 中，epochs 被定义为模块级开关。除了方便之外，还有什么理由必须在模块级别上吗？为什么不是翻译单元级别？
• 因此，与模块相比，这种行为是否可以通过#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

In P1881, the epochs are defined to be a module-level switch. Is there any reason why it has to be on the module level besides convenience? Why not translation-unit level?

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

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

---

could this behavior seamlessly achieved via #pragma's, provided compiler support or that would introduce severe technical difficulties (from the implementation or usage point of view) compared to the module-based proposal?

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

---

I do not see why it has to be modules.

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

我相信与模块级声明相比， block 作用域声明或 #pragma 有更多的误用机会。我还认为，将 epoch 绑定(bind)到模块将有助于开发人员在模块化现有代码库的同时考虑 epoch 迁移。

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