GNU bug report logs - #30039
26.0.90; [26.1] Making my code warning free is impossible with when-let

Previous Next

Full log

View this message in rfc822 format

From: Glenn Morris <rgm <at> gnu.org>
To: Nicolas Petton <nicolas <at> petton.fr>
Cc: Damien Cassou <damien <at> cassou.me>, 30039 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, npostavs <at> users.sourceforge.net
Subject: bug#30039: 26.0.90; [26.1] Making my code warning free is impossible with when-let
Date: Wed, 10 Jan 2018 12:24:04 -0500

Nicolas Petton wrote:

> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>>> That's a question we need to answer. I think supporting 2 releases would
>>> already be good (i.e., 26.1 does not deprecate but 26.2 does).
>>
>> That's not how we deprecate stuff.  We never wait with deprecation,
>> only with the actual removal.
>
> But in this case it leads to an issue with linting: when-let cannot be
> used in packages if we want to support both Emacs 25 and 26, since
> when-let has been deprecated and when-let* didn't exist in Emacs 25.

What's special about this case?
If you:
1) require a warning-free compilation in two releases of Emacs with the
same codebase
2) decline to use standard techniques such as https://debbugs.gnu.org/30039#11

then isn't the conclusion that *nothing* can be marked obsolete unless
the replacement existed in the previous release? Are you asking for this
to become Emacs policy?

Surely this would slow down the adoption of new techniques (because
people wouldn't start seeing the obsolescence warnings till another
release goes by).

I don't like compilation warnings either, but this position seems odd to
me.

Previous Next

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