What will (defun defun () 3) do?

Question

In a CppCon talk (https://www.youtube.com/watch?v=80BZxujhY38 at 5:00) Herb Sutter alluded to defun defun 3 being somehow a problem. After I googled it, it's still not clear to me why. Can someone elaborate?

Answer 1

In a comment from the same video:

Herb Sutter

See also the paper, P0707 (http://wg21.link/p0707), and search for "defun." Lisp defun (and Scheme define) lets you define a function... but in Lisp and Scheme you can even redefine built-in functions and macros, including defun/define itself which is what "defun defun" / "define define" does. Here's a sample related StackExchange question: https://emacs.stackexchange.com/questions/375/symbols-value-as-a-variable-is-void-defun-when-reloading-emacs .

I'm not interested in doing anything like that in C++, and there's nothing like that in my proposal, you can't change any definitions (including of this class after it is defined), you can't reach out and affect anyone else's type or code, the only thing you can do is participate in generating the one-time-and-then-immutable definition of this class you're writing right now which is nice and localized and bounded... and still very powerful.

The linked paper contains this section:

5.2.1 Problems in other languages

In Lisp and related languages, programmers can redefine other people’s code and even global language facilities (e.g., the notorious (defun defun () 3) in Lisp, or (define define () 3) in Scheme). This is powerful, but undisciplined (causes arbitrary global effects up to and including breaking the language itself), fragile (Lisp makes it notoriously easy to write “write-only” code that is difficult to review, read, and maintain), and causes programs to be tightly coupled among their components and with their developer’s environment (Lisp makes it notoriously easy to write code whose meaning depends on local customizations, is hard to share, and when shared is hard to compose with other code that came from an environment with competing assumptions).⁴

The footnote says:

⁴ Various incarnations and offshoots of Lisp attempted to mitigate this problem in various ways without actually taking away the root cause: Common Lisp added the guarantee that all symbols in the package COMMON-LISP are protected and must not be redefined by user code otherwise you get undefined behavior; although this provides some protection for the standard facilities, it does not solve the general problem because it still permits one set of user code to redefine things in another set of user code. Also, implementations like SBCL attempted to further improve the problem by providing ways to “lock” packages so their contents cannot be accidentally redefined; however, even SBCL also provides ways to “unlock” them again.