在CppCon演讲中（https://www.youtube.com/watch?v=80BZxujhY38在5:00）
赫伯·萨特（Herb Sutter）暗示defun defun 3可能是一个问题。后
我用谷歌搜索，但我仍然不清楚为什么。有人可以详细说明吗？
答案 0 :(得分：3)
在comment from the same video中：
草药萨特
另请参阅论文P0707（http://wg21.link/p0707），并搜索“ defun”。 Lisp defun（和Scheme定义）允许您定义一个函数...但是在Lisp和Scheme中，您甚至可以重新定义内置函数和宏，包括defun / define本身，这就是“ defun defun” /“ define define”的作用。以下是与StackExchange相关的示例示例：https://emacs.stackexchange.com/questions/375/symbols-value-as-a-variable-is-void-defun-when-reloading-emacs。
我对在C ++中进行类似的操作不感兴趣，并且在我的提案中没有类似的内容，您无法更改任何定义（包括定义后的此类的定义），您无法伸出手并影响其他人的类型或代码，您唯一可以做的就是参与生成您正在编写的此类的一次性且一成不变的定义，这是很好的，本地化的和有局限的...而且仍然非常功能强大。
linked paper包含以下部分：
5.2.1其他语言存在的问题
在Lisp和相关语言中，程序员可以重新定义其他人的代码，甚至重新定义全球语言设施（例如，臭名昭著的Lisp中的
(defun defun () 3)或Scheme中的(define define () 3)）。它功能强大，但没有规律（导致任意全局影响，甚至破坏语言本身），脆弱（Lisp使得编写“只写”代码非常困难，难以查看，阅读和维护），并且引起程序之间要紧密结合起来，并与开发人员的环境紧密结合在一起（Lisp使得编写依赖于本地自定义，难以共享，难以与环境中的其他代码组成的代码异常容易）竞争性假设）。 4
脚注说：
4 Lisp的各种化身和分支尝试以各种方式缓解此问题，而没有真正消除根本原因：Common Lisp添加了保证，包
COMMON-LISP中的所有符号都是受保护的，并且不能由用户代码重新定义，否则您将获得未定义的行为；尽管这为标准设施提供了一些保护，但是它不能解决一般问题，因为它仍然允许一组用户代码在另一组用户代码中重新定义事物。同样，诸如SBCL之类的实现也试图通过提供“锁定”软件包的方式来进一步改善该问题，以免意外地重新定义其内容。但是，甚至SBCL也提供了再次“解锁”它们的方法。