Re: Allow "true"/"false" phrasing in documentation

[Arsen Arsenović]

Stefan Kangas <stefankangas@gmail.com> writes:

> Hi all,
>
> I'd like to propose relaxing our documentation conventions to allow the
> use of "true" and "false" in place of "non-nil" and "nil", _where
> clarity isn't compromised_.  The idea is not to change semantics or
> terminology in API contracts or Elisp code, but to allow more natural
> phrasing where appropriate.
>
> This is not a proposal to replace "non-nil", only to allow "true" and
> "false" as equally valid phrasing where appropriate.
>
> Common Lisp has long treated `nil` as false and everything else as true,
> yet routinely uses "true" and "false" in documentation without
> confusion.[1]  Scheme does similarly (with #f/#t, but accepts anything
> non-#f as true).[2]  This usage even goes back to Maclisp.[3]
>
> Emacs Lisp works the same way: only `nil` is false, everything else is
> true.  So continuing to require "non-nil" in all cases feels
> unnecessarily verbose.
>
> For example, this sort of phrasing:
>
>     "If the argument is non-nil, then..."
>
> could become:
>
>     "If the argument is true, then..."
>
> when the precise value isn't material.  In contexts where the specific
> non-`nil` value matters (usually `t` vs. something else), we'd still use
> the usual terms.  But in general prose, "true"/"false" is equally
> correct and often clearer.

In some languages which, like Elisp, have true (t) and false (nil), the
terms "truthy" and "falsey" are used to this effect.  This prevents
confusion with the actual constant 'true' (t) and 'false' (nil).

This would mean no precision is lost while still having simpler wording.

I'm sharing this as another potential avenue to explore, IMO 'true' and
'false' are just as good, per your arguments.

Have a lovely day.
-- 
Arsen Arsenović

signature.asc
Description: PGP signature