In general, it's a good idea to just return; on failure, since return 0; will evaluate to TRUE in list context.

First, that's not true. You can't test the truthfulness of a something evaluated in list context, so how can it evaluate to true? I think you are talking about list assignment in scalar context.

sub is_valid { 0 }

is_valid()
   or die "invalid";         # Ok (dies)

my $invalid = is_valid()
   or die "invalid";         # Ok (dies)

my ($invalid) = is_valid()
   or die "invalid";         # XXX (Doesn't die!)
[download]

The last is purely the coder doing something wrong.

Secondly, I disagree. A boolean is expected, so return that. Otherwise, you create a function that needlessly returns differently when evaluated in scalar and list contexts. You create a function that returns something differently than expected (and documented?). You rely on the caller to create a boolean from the value you do return. For example, you are forcing people to write

%data = (
    foo => !!is_foo(),
    bar => !!is_bar(),
);
[download]

instead of

%data = (
    foo => is_foo(),
    bar => is_bar(),
);
[download]

Returning an empty list would cause the buggy assignment in scalar context to DWIM, but it breaks valid code.

Update: Improved list assignment in scalar context example.

I think we can both agree that the interface you specify should depend on how you are going to use it.

That's entirely my point. One would use the result of validate as a boolean, so it should return a boolean. You suggested that it should return something that needs to be converted into a boolean first.

Use a bare return to return failure

Return an empty list can be useful to signal failure where a false value could be returned.

sub get {
   $engine->connect()
      or return ();
   return $engine->get();
}

my $ok = ($data) = get();
[download]

That's not relevant here.

It only needs to be converted to a boolean first if it is used in a list assignment. Any usage of the sub in scalar context will behave as expected and as the original spec. We are both making assumptions about how "[o]ne would use the result", and any conclusions are subjective and academic.

We are both making assumptions about how "[o]ne would use the result",

Not at all. I'm saying you shouldn't introduce bugs in the design of a function based on the assumption that someone might misuse it.

If you can handle cases of misuse without compromising the design, that's great, but that's not possible here.

Any usage of the sub in scalar context will behave as expected

Correct. «return ();» in scalar context functions identically to «return undef;». That makes the behaviour in list context the deciding factor.

It only needs to be converted to a boolean first if it is used in a list assignment.

No. Here's an example without an assignment:

{ foo => validate($foo), bar => validate($bar) }
[download]

When using «return ();», the result needs to be converted to a boolean whenever validate is called in list context. That makes no sense for a function that's suppose to return a boolean.