all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Mattias Engdegård" <mattias.engdegard@gmail.com>
To: Basil Contovounesios <contovob@tcd.ie>
Cc: 64127@debbugs.gnu.org
Subject: bug#64127: 30.0.50; mutate-constant warning with pure function
Date: Sat, 17 Jun 2023 19:03:23 +0200	[thread overview]
Message-ID: <22FA3A9A-A113-437C-A338-15A2BA7ADA59@gmail.com> (raw)
In-Reply-To: <87jzw29hpq.fsf@epfl.ch>

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.






  reply	other threads:[~2023-06-17 17:03 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-17 11:32 bug#64127: 30.0.50; mutate-constant warning with pure function Basil Contovounesios via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-06-17 11:58 ` Mattias Engdegård
2023-06-17 16:28   ` Basil Contovounesios via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-06-17 17:03     ` Mattias Engdegård [this message]
2023-06-17 20:56       ` Basil Contovounesios via Bug reports for GNU Emacs, the Swiss army knife of text editors

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=22FA3A9A-A113-437C-A338-15A2BA7ADA59@gmail.com \
    --to=mattias.engdegard@gmail.com \
    --cc=64127@debbugs.gnu.org \
    --cc=contovob@tcd.ie \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.