Re: change to standard-char-p in SBCL 2.4.2

And the change to standard-char-p actually made type derivation
worse, (truly-the base-char char) didn't derive the char to base-char (it
was removed as unused).
The new constraints make either version derive to STANDARD-CHAR. So I'll
change it back to returning BOOLEAN.

On Sat, Mar 2, 2024 at 8:27 PM Stas Boukarev <[email protected]> wrote:

> Ok, I rectified that part.
>
> On Sat, Mar 2, 2024 at 7:58 PM Stas Boukarev <[email protected]> wrote:
>
>> It seems to solve the problem of
>> (when (< (char-code x) 100)
>>     x) ; => base-char.
>> but not in a general way.
>>
>> On Sat, Mar 2, 2024 at 7:56 PM Douglas Katzman <[email protected]> wrote:
>>
>>>
>>>
>>> On Sat, Mar 2, 2024 at 11:50 AM Stas Boukarev <[email protected]>
>>> wrote:
>>>
>>>> Is the better code only for the out-of-line function or does it have
>>>> any difference when inlined?
>>>>
>>>> If affects both. So while we could say that the full-called version
>>> returns a strict boolean (because the wrapper stub forces T/NIL), that
>>> would be really weird obscure policy-sensitive behavior
>>>
>>

_______________________________________________
Sbcl-help mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sbcl-help