Subject: bug#77725: 31.0.50; Add support for types accepted by `cl-typep' to cl-generic?

From: David Ponce <[email-masked]>
Date: Thu, 8 May 2025 17:27:14 +0200

On 2025-05-08 16:56, Stefan Monnier wrote:
>>    (cl-defmethod cl-generic-generalizers :extra "derived-types" (type)
>>      "Support for dispatch on derived types, i.e. defined with `cl-deftype'."
>>      (if (and (symbolp type) (cl-derived-type-class-p (cl--find-class type))
>>               ;; Make sure this derived type can be used without arguments.
>>               (let ((expander (get type 'cl-deftype-handler)))
>>                 (and expander (with-demoted-errors "%S" (funcall expander)))))
>>          (cl--derived-type-generalizers type)
>>        (cl-call-next-method)))
>>
>> Could now be simplified like this:
>>
>>    (cl-defmethod cl-generic-generalizers :extra "derived-types" (type)
>>      "Support for dispatch on derived types, i.e. defined with `cl-deftype'."
>>      (if (and (symbolp type) (cl-derived-type-class-p (cl--find-class type))
>>               ;; Make sure this derived type can be used without arguments.
>>               (memq type cl--derived-type-list)) ;; <<<<<<<<<<<<<<<<<<<
>>          (cl--derived-type-generalizers type)
>>        (cl-call-next-method)))
> 
> Yes, or we could check (get type 'cl-deftype-satisfies), but I think
> here if (funcall expander) signals an error we want the user to know,
> because when (cl-derived-type-class-p (cl--find-class type)) is true, it
> means *we* are the generalizer that should be in charge and an expander
> error means there's an error elsewhere, most likely in TYPE itself.
> That's also why I changed the `ignore-errors` to `with-demoted-errors`.
> 

Ah, OK, it makes sense. Thank you!

> Actually, I think this expander test should be moved to
> `cl--derived-type-generalizers` so we don't keep trying with
> other generalizers.

It would be better, yes.

Have a nice day.
David