Usefulness of (t nil) as the last sexp in (cond ...) constructs?

Usefulness of (t nil) as the last sexp in (cond ...) constructs?

[Bastien]

There are many places in *.el elisp files where we have this construct

(cond (...)
      (...)
      (t nil))

My understanding is that (t nil) is useless, since the ̀t' condition 
is only tested if other conditions are `nil'.

What is the purpose of (t nil)?

Can we safely remove it?

-- 
 Bastien

Re: Usefulness of (t nil) as the last sexp in (cond ...) constructs?

[Jeremiah Dodds]

Bastien <bzg@altern.org> writes:

> There are many places in *.el elisp files where we have this construct
>
> (cond (...)
>       (...)
>       (t nil))
>
> My understanding is that (t nil) is useless, since the ̀t' condition 
> is only tested if other conditions are `nil'.
>
> What is the purpose of (t nil)?

IIRC, it's mostly there to make it explicit that "this cond is expected
to return nil sometimes".

> Can we safely remove it?

Again, IIRC, it shouldn't affect behaviour to do so, but it might not be
preferable. 

-- 
Jeremiah Dodds

blog       : http://jdodds.github.com
github     : https://github.com/jdodds
freenode   : exhortatory
twitter    : kaens

Re: Usefulness of (t nil) as the last sexp in (cond ...) constructs?

[Achim Gratz]

Bastien writes:
> There are many places in *.el elisp files where we have this construct
>
> (cond (...)
>       (...)
>       (t nil))
>
> My understanding is that (t nil) is useless, since the ̀t' condition 
> is only tested if other conditions are `nil'.
>
> What is the purpose of (t nil)?

It's a nice (redundant) reminder that "if none of the other conditions
is true, this form returns nil".

> Can we safely remove it?

I don't know if any checkers rely on it.  I'd expect it is optimized
away when the byte-compiler gets to it anyway, so why would you want to
remove it?


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Downloads.html#KomplexerWaves

Re: Usefulness of (t nil) as the last sexp in (cond ...) constructs?

[Thien-Thi Nguyen]

[-- Attachment #1.1: Type: text/plain, Size: 207 bytes --]

() Achim Gratz <Stromeko@nexgo.de>
() Sun, 19 Aug 2012 13:29:52 +0200

   I'd expect it is optimized away when the byte-compiler [...]

Well, no (not yet, until Someone teaches the byte-compiler about it):


[-- Attachment #1.2: cond-t-nil --]
[-- Type: application/x-emacs-lisp, Size: 722 bytes --]

[-- Attachment #1.3: Type: text/plain, Size: 377 bytes --]


-- 
Thien-Thi Nguyen ..................................... GPG key: 4C807502
.                  NB: ttn at glug dot org is not me                   .
.                 (and has not been since 2007 or so)                  .
.                        ACCEPT NO SUBSTITUTES                         .
........... please send technical questions to mailing lists ...........

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: Usefulness of (t nil) as the last sexp in (cond ...) constructs?

[Bastien]

Achim Gratz <Stromeko@nexgo.de> writes:

> It's a nice (redundant) reminder that "if none of the other conditions
> is true, this form returns nil".

Okay.  In many cases, this reminder is not useful, as it is obvious from
the code.  I've removed (t nil) in such cases in org-mode git repo.

-- 
 Bastien

Re: Usefulness of (t nil) as the last sexp in (cond ...) constructs?

[Juanma Barranquero]

On Sun, Aug 19, 2012 at 9:07 AM, Bastien <bzg@altern.org> wrote:

> Can we safely remove it?

Yes.

Should we?

No, IMHO.

    Juanma