bug#69739: 30.0.50; `type-of` is not precise enough

[Stefan Monnier]

Basil L. Contovounesios [2024-03-15 10:51:33] wrote:
> No objections here, just one question: did you consider extending
> type-of with an optional argument instead of introducing cl-type-of?
> Or would that be too messy?

I did.  I decided to introduce a new function for the following reasons:

- The main use for the new function is in the dispatch code of
  `cl-generic` where it's on the critical path, so one less argument is
  better than one more argument.  Not sure how much impact it would
  really have, tho, so it's not a very strong argument.
- I don't know of a good reason to prefer the `type-of` behavior other
  than backward compatibility, and requiring a non-nil arg to get the
  "good" behavior would make it difficult to get rid of the
  legacy behavior.


Andrea Corallo [2024-03-15 06:54:36] wrote:
> FWIW: I think this is a good change and agree `cl-type-of` is a good
> name for the new function.  I'm just wondering if we should have some
> test to cover this.

Are you suggesting that my code can be anything else than perfect?
More seriously, I couldn't think of a good test, but I'll try harder.

Eli Zaretskii [2024-03-15 13:50:56] wrote:
> Should we document this new function in the ELisp manual?

I was thinking that we should do that only when/if we demote `type-of`
(`(cl-)type-of` is an operation that's used very rarely, so I think it's
best to keep it to a minimum in the manual),
Of course, the name also begs the question whether it should be in the
ELisp manual or in the CL manual.

In a previous version of the patch I had it documented alongside
`type-of`, so I can easily dig that up if you think it's best.


        Stefan