GNU bug report logs - #64127
30.0.50; mutate-constant warning with pure function

Previous Next

Full log

View this message in rfc822 format

From: Mattias Engdegård <mattias.engdegard <at> gmail.com>
To: Basil Contovounesios <contovob <at> tcd.ie>
Cc: 64127 <at> debbugs.gnu.org
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 <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.