Thanks, Eli and Andrea.

Date: Mon, 30 Jun 2025 03:31:53 -0400, Andrea Corallo writes,

> > Another question is about `compilation-safety'. As I understand it, when
> > set to 1, it prevents Emacs from crashing due to faulty
> > optimizations. Does this mean the variable only guards against the most
> > severe cases, rather than ensuring the correctness of optimizations in
> > general?
> 
> The doc for compilation-safety says:
> 
> "Possible values are:
>   0 - emitted code can misbehave, even crash Emacs, if declarations of
>       functions do not correctly describe their actual behavior;
>   1 - emitted code is to be generated in a safe manner, even if functions
>       are mis-declared."
> 
> The situation for 'compilation-safety' with the current code in case of
> incorrect declarations is:
> 
> 0 we perform optimizations, code can even crash.
> 1 it cannot crash but still we can perform some otimizations (which can
>   produce unexpected results at execution time).

Thank you for the explanation -- I now understand that when
`compilation-safety' is set to 1 (the default), it generates code in a
safer manner that avoids crashes, even if function declarations are
incorrect. However, it does *not* guarantee the correctness of the
generated code in such cases.

> If we are unsatisfied with this granularity we could introduce a new value:
> 
> 2 no optimizations are performed based on function type declarations.
> 
> Mmmh maybe is not a bad idea.

Mmm, I somewhat agree with this idea. I actually discovered the
consequences of incorrect type declarations while running code under ERT
tests, but it¡¯s a kind of issue that's not immediately obvious as being
caused by a misdeclared type. If adding this option wouldn¡¯t be too
much trouble, please consider implementing it. TIA!

By the way, would introducing this option affect native-comp-speed?
Since if we had a possible value of 2, optimizations wouldn¡¯t rely on
type declarations anymore.

Another possible improvement might be to clarify the docstring for
compilation-safety. I mean, making it more explicitly state that it
ensures *safety*, but does not guarantee *correctness*.