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

Question

在P1881 proposal, the concept of epochs (on a module level) for the C++ code is proposed. Such functionality can allow customization of the C++ syntaxis and C++ behavior on the level of the module without necessarily breaking backward compatibility. More elaborate motivation is given in the proposal。

提案中的隐式转换示例

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

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

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

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?

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

I do not see why it has to be modules.

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

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

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

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

C++ module-based epochs in P1881 vs potential #pragma-based epochs

c++

standards

pragma

c++-modules

提案中的隐式转换示例