Re: Introducing 'safety' compilation parameter

[Andrea Corallo <acorallo@gnu.org>]

Andrea Corallo <acorallo@gnu.org> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>>> I didn't want to give safety a prefix (byte- or comp-) as I believe we
>>> should extend safety in the future with a value to have the byte
>>> compiler generates runtime type checks to verify the declred types.
>>
>> I don't see a strong need for a namespace prefix, but I think "safety"
>> is too general a term.  It could be understood to apply also to
>> unrelated circumstances such as process confinement or disclosure of
>> sensitive info over a network connection.
>> Maybe `elisp-safety` or `compilation-safety`?
>
> Agree, boths SGTM, maaaybe I slightly prefer 'compilation-safety'.
>
>> If I read your patch correctly, we get safety in a roundabout way:
>> rather than test the safety setting at the spot where we decide to apply
>> (or not) a dangerous optimization, we use the safety setting to
>> "mollify" the type annotations (presumably because this will in turn
>> make the risky optimizations inapplicable).
>>
>> What is the reason for that?
>
> No specific reason, I think I thought was safer to write the patch with
> way gating optimization at this (higher) level.  Thinking about now that
> you raised the point, is probably easy to gate the single optimizations
> as well.  Why not, I think I'll update the patch this way.

Okay I pushed scratch/comp-safety2 changing the knob name to
'compilation-safety' and gating the dangerous optimizations as
discussed.

Thanks

  Andrea