>
> I've run into this sort of problem a lot (0-long input to sapply
> causes it to return list()). A related problem is that when sapply's
> FUN doesn't always return the type of value you expect for some
> corner case then sapply won't do the expected simplication. If
> sapply had an argument that gave the expected form of FUN's output
> then sapply could (a) die if some call to FUN didn't return something
> of that form and (b) return a 0-long object of the correct form
> if sapply's X has length zero so FUN is never called. E.g.,
> sapply(2:0, function(i)(11:20)[i], FUN.VALUE=integer(1)) # die on
> third iteration
> sapply(integer(0), function(i)i>0, FUN.VALUE=logical(1)) # return
> logical(0)
>
> Another benefit of sapply knowing the type of FUN's return value is
> that it wouldn't have to waste space creating a list of FUN's return
> values but could stuff them directly into the final output structure.
> A list of n scalar doubles is 4.5 times bigger than double(n) and the
> factor is 9.0 for integers and logicals.

That sounds like a good idea. It would be a bit of work, because the
current sapply depends on lapply while this would need its own internal
implementation: but it would probably be worthwhile.