Subject: bug#34338: 26.1; delete-file return codes and failures

From: Eli Zaretskii <[email-masked]>
Date: Thu, 31 Oct 2019 16:01:15 +0200

> Date: Wed, 30 Oct 2019 18:22:00 -0400
> From: Boruch Baum <[email-masked]>
> Cc: Eli Zaretskii <[email-masked]>, [email-masked]
> 
> How is it backwards incompatable? If the prior behavior was undefined,
> no one would have been using it for anything. From their perspective, a
> defined is just another form of undefined behavior, if you get my drift.

My "backward-incompatible" response was only related to your
suggestion to signal an error when a file doesn't exist, and/or modify
the function's signature in incompatible ways.  I didn't object to
making this function return a meaningful value, if the argument list
remains compatible, i.e. if existing code doesn't need to change.

However, if we make the function return meaningful values, we must
make sure it always does so, and in consistent manner.  For example,
the file handlers should be documented to return the same values (and
existing handlers should be modified to actually do so), moving the
file to trash, whether via a system-dependent primitive or application
code in files.el, should return the same value for the same
conditions, etc.