论属性的可忽略性

这是一篇关于 C++ 中属性(attributes)相关讨论的文章,主要观点如下:

  • 属性不适合某些角色:属性被证明不适合“小特性”“对大特性的小修改”或其他语言的注释等角色,需要一种新的不可忽略的注释,且建议只使用一种语法来满足所有需求。
  • [[attributes]]的引入:C++11 提案的最后修订引入了[[attributes]],提供了更好的语法和精确的归属规则,避免了发明新关键字和处理语法的问题,但后来align又变为关键字。同时给出了使用属性的指导原则,但一些示例中的属性明显影响了程序的意义。
  • [[override]]的消亡[[override]]属性最初用于解决函数重写相关问题,满足最初属性论文的所有标准,但后来被改为上下文关键字,导致了不一致性、需要讨论使用的标记等问题,破坏了属性避免这些问题的初衷。
  • 损害过去的语言演化:C++11 中[[override]][[final]]本可作为属性却变为上下文关键字,之后又有[[deprecated]][[nodiscard]]等属性的引入,导致在引入新的诊断设施时出现了多种选择,基础不稳固。
  • 谁从忽略属性中受益:有人认为编译器忽略属性可使使用未支持属性的库在旧编译器上工作,但实际上忽略属性可能导致编译器忽略错误,且有更好的方法处理未实现的属性,如显式声明。[[no_unique_address]]的忽略会导致 ABI 破坏,是属性不应被忽略的例子。
  • 损害当前的语言演化:C++26 的 trivial relocation 特征因是上下文关键字而非属性,导致实现复杂且存在歧义解析问题,本可直接用属性解决。
  • 损害未来的语言演化:讨论了其他可能采用的语言特征,如[[gnu::packed]][[clang::lifetimebound]][[gnu::constructor]]等,由于属性的限制,这些特征在标准化时会面临诸多讨论和选择难题,且当前语言中未充分利用[[noreturn]]等属性。
  • 非忽略属性的必要性:我们有添加更多实体信息的设施,但却限制其不能做任何事,导致人们追求新的不可忽略的属性,同时花费时间解决自身制造的问题,这种状况需要改变。

关键信息和重要细节:

  • 文中多次提到不同的属性提案及相关讨论,如N2761N2928N3151等,以及它们的变化和影响。
  • 详细阐述了属性在语法、语义、兼容性等方面的问题和带来的后果。
  • 举例说明了各种属性在实际代码中的应用和争议,如[[override]][[no_unique_address]]等。
  • 强调了属性在语言演化中的重要性以及当前限制属性的不合理性。
阅读 9
0 条评论