[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#64127: 30.0.50; mutate-constant warning with pure function
From: |
Mattias Engdegård |
Subject: |
bug#64127: 30.0.50; mutate-constant warning with pure function |
Date: |
Sat, 17 Jun 2023 19:03:23 +0200 |
17 juni 2023 kl. 18.28 skrev Basil Contovounesios <contovob@tcd.ie>:
> Which approach do you think the dash.el library in GNU ELPA should
> follow? It generally defines nondestructive operations over lists, some
> of which even claim in their docstring that they return a partial or
> complete copy of their arguments (modulo the parts changed by the
> operation).
Its doc strings seem to talk a lot about how the functions returns a new this
or a copy of that. Maybe that provides the licence to return a constant when
those words are absent, or perhaps the users will just assume mutability in
absence of stern warnings. I don't know how dash.el is used in practice, so
perhaps it's prudent to stay off the `pure` declarations.
> Is it okay for a pure function to say it returns a copy in its
> docstring, with the onus lying on the caller to realise that a pure
> function call may be byte-compiled to a runtime constant? Or should all
> such functions be impurified?
A pure function cannot in general be guaranteed to return an eq-unique value.
By definition it will, if all its arguments are constants, be called at
compile-time to generate a constant used in the program.
There is nothing wrong with returning a newly created object from a
`pure`-declared function, as long as reasonable steps are taken to prevent the
returned value from being mutated. Depending on the context this can be as
simple as not saying that it returns a new object.