Re: [PATCH 3/6] Remove return undef from ask()

[Jeff King <peff@peff.net>]

On Wed, Apr 29, 2009 at 09:12:20AM -0400, Bill Pemberton wrote:

> Returning undef is rarely the correct way to return a failure.
> Replace it with bare return

I'm not sure this makes sense. The function is meant to be (and is
always) called in a scalar context, so "return" and "return undef"
produce exactly the same results. I find the latter much more clear,
because it is explicit about what the function is doing: return the
user's desire; if that fails, return the default; if no default, return
undef.

Returning undef can be a problem for programs which are meant to be used
in list context; you generally want to return the empty list in that
case (not a list with a single undef in it). So that is the reason for
the advice you are quoting.

I am not sure it is worth making this function behave properly in a list
context; it is not a library function, so we can see that all of the
existing callers use it in a scalar context (and we would have to define
sensible semantics for a list context). But even if we _did_ want to do
that, your patch is only the first step. You would have to also fix the
other returns which can return undef instead of an empty list. So there
is not much point to your patch as it stands.

On a side note, while looking at this function, I wonder if that "return
undef" is correct after all. We get there only if the user has failed to
give valid input 10 times, so presumably it is a sanity check to
prevent runaway input errors (and I am cc'ing Jay, who added the
function not too long ago). Should we be respecting the default here, as
we do when we get EOF? Although I tend to think if the user is
repeatedly giving us bogus input that we should not just proceed, but
should probably die. Because otherwise we are guessing at what they
might have wanted.

-Peff