支持重用短关键字（并添加上下文相关的含义）而不仅仅是添加更多关键字的主要论点是什么？
只是你想避免现有的代码，可能已经使用了一个新的关键字，或者有更深层次的原因？
C ++ 11 中的新“枚举类”让我想到了这一点，但这是一个通用的语言设计问题。
只是你想避免现有的代码，可能已经使用了一个新的关键字，或者有更深层次的原因？
不，这就是原因。
根据定义，关键字总是被认为是关键字，无论它们在源中出现在哪里，因此它们不能用于其他目的。将某个东西作为关键字会任何可能将该令牌用作变量、函数或类型名称的代码。
C 委员会采取不同的方法，并使用_Reserved 名称添加新关键字，例如_Atomic，_Bool，然后他们添加一个新的标题（<stdatomic.h>，<stdbool.h>）与一个更好的宏，以便您可以选择是否包含标题以自动获取名称atomic或bool
C ++ 委员会不喜欢宏，并希望它们是正确的关键字，因此要么重新使用现有的（例如auto），要么添加上下文相关的“关键字”（这不是真正的关键字，而是“具有特殊含义的标识符”，因此它们可以用于其他事物，例如override），或者使用不可能与用户代码冲突的奇怪拼写。
一些旧语言根本没有关键字，特别是PL/1其中
IF IF=THEN THEN BEGIN;
/* some more code */
END;
是一段合法的代码，但完全不可读。(也可以看看APL作为write-mostly编程语言的例子，几个月后，即使是代码的原作者，也完全看不懂)。
C 和 C++ 语言家族有一组由语言规范定义的关键字。但是有非常广泛使用的语言,有数十亿的遗留源代码行。如果你 (或他们的标准化委员会) 添加一个新的关键字,就有可能与一些现有的程序发生冲突,正如你所猜到的,其他人回答这是坏的。因此,如果标准添加了例如enum_class作为新的关键字,那么当有人不高兴地将其实体用作
此外，众所周知，C ++ 的解析速度很慢（特别是，因为像<vector>这样的标准头文件正在拉动十几千行源代码，并且因为模块还不在 C ++ 中，并且因为语法非常模糊），所以复杂的解析器来处理新的语法并不是什么大问题（解析 C ++ 显然比解析新的 C 库更难）。
其他一些语言（例如 Lisp 的一些方言，例如Common Lisp和一些Scheme，您可以在其中重新定义let或if宏，以及macros在iconic语言中的现有非常不同，因为在4替换 s
我认为这主要是因为添加关键字会现有的代码,这些代码恰好在其他上下文中使用此关键字,正如您所建议的那样。
只是你想避免现有的代码，可能已经使用了一个新的关键字，或者有更深层次的原因？
根据定义，关键字是一种特殊的标记，不能在其他任何地方使用；因此，引入关键字会使用给定拼写的标识符的任何代码。
某些语言使用术语上下文关键字来指代仅在特定上下文中解释为关键字的拼写。如果以前在此上下文中不能使用“wild”标识符，则可以保证上下文关键字的引入不会现有代码。例如，由于在函数签名中，没有标识符可以立即出现在右括号之后，因此可以在此处引入所谓的上下文关键字（例如或0）。
另一方面，在以前允许使用任何标识符的地方，添加关键字会带来风险。例如：
struct H { my_type f; enum { g }; };：使用enum class而不是 new 关键字是因为在这种情况下，任何新词都可能被错误地用作数据成员声明的开头；只有一个关键字是明确的（在 LL（1）中），并且引入一个新的关键字可能会代码。
void h() { my_type f; auto x = g(); }：使用auto而不是新关键字是因为任何新词都可能与现有类型冲突。这仍然是一个令人惊讶的选择，因为它已经是 C中位置可用的关键字（默认为int类型），但其含义已更改（理由是其使用的可能性很低）。
正如一些人提到的那样，语言可以完全没有关键字（Haskell 非常接近），或者可以无缝地引入关键字（例如，如果每个声明都已经以关键字开头，那么引入一个新的关键字就不能冲突）。
本站系公益性非盈利分享网址，本文来自用户投稿，不代表码文网立场，如若转载，请注明出处
评论列表（82条）