Hi Lester,
On Fri, Feb 27, 2015 at 6:51 PM, Lester Caine <les...@lsces.co.uk> wrote:
> This may not be what YOU want substr to do and it would perhaps be
> useful to ADD additional checks so that 'false' is returned when it
> can't created a string because of the 'invalid arguments', but type
> hints makes no difference to part of the jigsaw. What happens is exactly
> what one would expect ... nothing left in the string -> an empty string.
> Having then to check every time for a '0' string length got shortened to
> simply being able to check 'is there a string' yes/no, and if no you can
> do something else. There is nothing inconsistent ...
>
Please, read the examples again, the current behavior is nothing but
inconsistent:
substr("a", 1) => FALSE
substr("a", -300) => ""
But anyway, that's not even the point. The point is that return values that
"worked" in a world of transparent type-jungling will not work in a world
of stricter typing checks. Which means that we need:
(1) To accept that for now casting FALSE to the empty string is the right
thing to do;
until / unless:
(2) We fixed all the common functions in the standard library so that they
stop returning inconsistent types, in particular in the cases where it
should not even be a debate what is the right thing to do (for substr, if
the arguments point to an empty slice, return the empty string).
Damien
