[...]
>> That's fine with me.  I asked because it seemed to me that it wasn't
>> recommended to load cl-macs but rather cl-lib.
> 
> Yes, but that worked OK because in order to *use* those types you needed
> to use `cl-deftype` or `cl-typep`, both of which are autoloaded from
> `cl-macs.el`.

You are right, I forgot that, sorry.

>>> Some of those types are virtually never used, so maybe we'll want to
>>> move some but not all?
>> To be honest, I don't know if/when these types are used.
> 
> `grep` can provide some answers to that question.  🙂

Sure ;-)



Please find attached a proposal to improve error handling in
`cl-types-of'.  Ultimately, I think you were right and it is better to
simply report derived type errors to the caller and abort processing,
but while also preventing their recurrence as much as possible :-)

So my proposal is to still handle any error on a derived type, in
order to disable the type as is currently done by removing it from the
list of types; but, instead of warn, raise a new `cl-type-error'
mentioning the type in error and the underlying error.  Here are some
simple examples for you to observe the result.

(cl-deftype T1 ()
   '(satisfies plusp))

(cl-types-of -0.5)
=> (real float number number-or-marker atom t)

(cl-types-of 12)
=> (T1 real base-char character fixnum natnum integer number integer-or-marker number-or-marker atom t)

(cl-types-of "12")
=> Error on derived type: T1, (wrong-type-argument number-or-marker-p "12")

(cl-deftype T2 ()
   `(satisfies ,(lambda (o) (memq 'T1 (cl-types-of o)))))

(cl-types-of "12")
=> Error on derived type: T2, (excessive-lisp-nesting 1601)

Does it make sense?

Thanks!
David