bug#9712: 24.0.50; doc about byte-compiling `defcustom'

["Drew Adams" <drew.adams@oracle.com>]

Is this maybe more than a doc bug?  In bytecomp.el there is this:

(defun byte-compile-file-form-custom-declare-variable (form)
  (when (byte-compile-warning-enabled-p 'callargs)
    (byte-compile-nogroup-warn form))
  (push (nth 1 (nth 1 form)) byte-compile-bound-variables)
  ;; Don't compile the expression because it may be displayed to the user.
  ;; (when (eq (car-safe (nth 2 form)) 'quote)
  ;;   ;; (nth 2 form) is meant to evaluate to an expression, so if we have the
  ;;   ;; final value already, we can byte-compile it.
  ;;   (setcar (cdr (nth 2 form))
  ;;           (byte-compile-top-level (cadr (nth 2 form)) nil 'file)))

Seems like this non-evaluation is intended, but sounds like the designer is not
sure that's a good idea (?).  What does "because it may be displayed to the
user" mean?  Is the idea that the user would see the byte-compiled value instead
of the code that evaluates to that value?  If so, why is that bad?

At any rate, there is at least a doc bug.  In particular, someone who wraps the
`defcustom' VALUE in `eval-when-compile' will mistakenly expect the evaluation
result to be placed into the byte code as a constant.  S?he will not expect that
VALUE is not evaluated at byte-compile time, even when inside
`eval-when-compile'.

A consequence of the current behavior is that you really cannot use macro calls
in VALUE, unless you are sure that the macro definition will be available also
at load time (i.e., byte-compilation time is not enough).  I ran into this using
macro `kbd' in VALUE.