Re: __tostring and string.format

[Javier Guerra Giraldez <javier@...>]

On Mon, Dec 6, 2010 at 9:39 AM, Roberto Ierusalimschy
<roberto@inf.puc-rio.br> wrote:
>> >>But then we could ask the very same question about table.concat, which
>> >>also doesn't use tostring...
>> >Why should it?
>> Because it would be convenient. Are there any reasons for tostring()
>> not to be called in these 2 cases?
>
> Robustness? Several errors (e.g., a nil value) will be silently
> supressed by 'tostring'. For '%s' this is not such a problem, as usually
> we see the result, so it is easy to spot bugs. In table.concat, however,
> it may cause some pain for debugging.


in my book, a function that (within reason) normalizes its input is
more robust than one that fails.

of course, consistently failing is immensely more robust than
producing undesirable output on questionable input.

unfortunately, pre-screening a table before concat()ing it feels
clunky.  a mapconcat() function would be nice,  but that seems a good
candidate for a user library, not the core one.  borrowing from
Scheme, i'd like a fold() that could produce an efficient replacement
to concat() when used with some core-provided string accumulation
function.

-- 
Javier