updates of defclass when underlying deftype changed

[Martin Cracauer]

"1.0.56.66.HEAD.78-546012b"

(deftype color-name () '(member :red :green :blue))
 (defclass color () ((color :type color-name :initarg :color)))
 (make-instance 'color :color :white)

==> error as expected.

However, redefining color-name doesn't lead to an update of color.

;; put this into a Lisp that previous executed the above lines
(deftype color-name () '(member :red :green :blue :white))
 (defclass color () ((color :type color-name :initarg :color)))
 (make-instance 'color :color :white)

==> still an error but shouldn't.

Credit for reporting goes to swm.

[Martin Cracauer (cracauer)]

subject typo
s/updates of defclass when underlying deftype failed/updates of defclass when underlying deftype changed/

[James Y Knight (foom)]

BTW: this is a regression; it worked in version 1.0.29.11, at least. But I haven't attempted to bisect it.

[Nikodemus Siivola (nikodemus)]

My first guess would be regression from 0223f43d5f199914ebceff12b6f4c60448369edd:

    1.0.46.11: faster slot-accesses in the presence of SLOT-VALUE-USING-CLASS &co

the commit message containing this:

     * WRAPPER-INSTANCE-SLOTS-LAYOUT now also includes slot-types, and we consider
       the instance to be obsoleted when slot-type changes. (This was a bug that
       our previous type-check-function setup accidentally worked around.)

[Christophe Rhodes (csr21-cantab)]

I'm slightly surprised that this is being considered a bug.

In e.g.

(deftype color-name () '(member :red :green :blue))
(defmacro color-twice (color) `(list ,color ,color))
(defun foo (x)
  (declare (optimize safety) (type color-name x))
  (color-twice x))

I would expect a compiled function FOO to not do a run-time lookup of
the COLOR-NAME type, but to use the type definition which was in effect
at the time of FOO's definition. So, just as a change in COLOR-TWICE
would mean that FOO would need recompilation, a change in COLOR-NAME
would mean that users of the type would need recompilation.

The analogy in terms of defclass is clear:

(defclass foo ()
  ((two-colors :initform (color-twice :red) :type (cons color-name color-name))))

A change in COLOR-TWICE would need FOO to be reevaluated, because the
resolution of the initform into an initfunction occurs when the defclass
form is evaluated -- and the mechanism for slot types is pretty much
analogous.

[Douglas Katzman (dougk)]

This isn't a bug because re-evaluating a DEFTYPE invokes unspecified behavior.
Also, reevaluating the defclass - spelled identically such as it is - does not generate a new LAYOUT instance because nothing about the definition changed. An "incompatible" definition might kick out the cached constructor. (You might think it's already different enough because it references a different type, but for whatever reason, it's not)

At best this could be considered a wishlist item, though I prefer it as a wont-fix.
Reopen if you feel otherwise.