Earlier quoted context omitted.
There isn't necessarily an actual type error! Remember, the declaration provided by the user can be an inaccurate estimate of what the real type constraint is at that program node. The program might in fact require a string there, but the programmer's declaration says integer. So the assertion goes off when a string value occurs, when that would in fact correct in the absence of the declaration. This alteration of be…
If you re-read everything in this subthread, you'll find a lot of argument from seasoned lispers that I can and should ignore the fact that type declarations are unsafe even at the highest safety settings because of "what implementations do." If this discussion had taken place before SBCL, the logical conclusion from what these seasoned lispers say would have been that I can and should use type declarations in safe c…
The word "safe" in Lisp is tied to run-time checks.
"Less safe" means fewer run-time checks.
If a declaration causes a check to be inserted which signals a condition in code that otherwise would not, that isn't "unsafe"; it is something else. "Unsafe" in Common Lisp specifically means that a check didn't take place which normally would take place.
A monotonic increase in the variety of checks performed at run-time cannot be called "unsafe"; that amounts to an incorrect use of the ANSI document's defined term.
You can say that adding declarations to a program is "risky": it creates the risk that conditions will be signaled.
Those extra behaviors are in fact allowed because the program has violated a declaration, which is undefined behavior. That is a very general statement in the standard which is not expected to have malicious interpretations. Declarations are part of the program and can change its behavior; it is not spelled out in detail how, but the optimization parameters like safety and speed have obvious interpretations.
If a declaration is processed for safe code, and a behavior is added other than a diagnostic behavior, that could be characterized as malicious. For instance, supposed the program abruptly stops, without any diagnostic, so that it is not known why. That would not be acceptable. It would not be acceptable for a variable to be mysteriously altered, and for computation to continue, so that a problem occurs later which is nigh impossible to trace back to the violated declaration.
If you think the implementors are malicious, use something else. Malice could be perpetrated in almost any area of an implementation.
Think about it. Suppose you're hoping to use declarations to speed up code. You add the declarations and keep the code safe at first. If declarations are completely ignored, you're not getting any help! The code is working exactly as before and then when you drop safety and add speed, it fails. It fails not in nice ways, but catastrophically, due to reasons that could have been caught had the declarations been processed in safe mode.