bug#42147: 28.0.50; pure vs side-effect-free, missing optimizations?

[Philipp Stephani]

Am Mo., 3. Aug. 2020 um 17:07 Uhr schrieb Mattias Engdegård <mattiase@acm.org>:
>
> 29 juli 2020 kl. 22.39 skrev Stefan Monnier <monnier@iro.umontreal.ca>:
> >
> >> Regarding package-get-version: perhaps we should drop the 'pure' property
> >> and just let callers wrap it in eval-when-compile?
> >
> > I'd rather not: the benefit is too subtle, I'd expect most users won't
> > know/bother to use `eval-when-compile` around it even though I'd expect
> > a vast majority of the uses can benefit from compile-time evaluation.
> > In contrast the cases where the impurity will get in the way
> > should be rare.  Feel free to add a `save-match-data` if you think it's
> > worth the trouble (but please include a comment explaining it's only
> > there in order to satisfy the `pure` annotation).
>
> Thank you, I'll let you make the decision since you introduced the function. 
> Another possibility would be to turn it into a macro again (or more likely a 
> macro that calls a function at compile-time), or use define-inline.
>

Another option would be to create a separate function property (such
as `eval-when-compile' or `force-inline') that would force the byte
compiler to inline each call, as if surrounded by `eval-when-compile'.