Hi Andreas,

In this particular case, the `string-trim-*` family of functions panic with the rather unhelpful `Wrong type argument: stringp, nil` message when passed `nil`, so the initial `when` is guarding against that. Since `nil` exists as a "bottom" value to every type in Elisp (not unlike C's null pointers), we adopt the C approach of "don't trust what we're given, and expect the user to check what they're returned". Such scenarios are precisely what macros like `when-let` are for, as far as I can tell.

In general this approach is founded upon the ideas that:

1. `nil` is a good general signal for logical failure (for languages that lack generics, etc.).
2. Library code shouldn't crash/panic (but user code should feel free to).
3. It's okay to return `nil` if the docstrings are clear about when that happens.

Please let me know if I've overlooked something, I'm happy to revise the patch.

Cheers,
Colin

On Wed, 26 May 2021, at 00:34, Andreas Schwab wrote:
> On Mai 25 2021, Colin Woodbury wrote:
> 
> > +Returns nil if either of the FILENAME or EXTENSION are nil before
> > +dot consolidation, or empty afterwards."
> > +  (when (and filename extension)
> 
> I still don't see any reason to allow nil.  A file name is always a
> string.
> 
> Andreas.
> 
> -- 
> Andreas Schwab, schwab@linux-m68k.org <mailto:schwab%40linux-m68k.org>
> GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
> "And now for something completely different."
>