Re: __tostring and string.format

[Duncan Cross <duncan.cross@...>]

On Mon, Dec 6, 2010 at 3:37 PM, Roberto Ierusalimschy
<roberto@inf.puc-rio.br> wrote:
>> I'm confused by what you mean here. table.concat(), like all the other
>> table functions like table.sort() and table.insert(), expects to take
>> a valid Lua array-table and if you pass it one with nils/holes in, it
>> usually raises no error and just has undefined results. We are
>> expected to know and understand this for the other functions, why not
>> table.concat() too?
>
> Sorry, the nil example is not a good one ;) Any other type will do. For
> instance, if you add a function to a table and then call 'table.concat',
> do you really want to have 'function: 0x9fb7020' in the resulting
> string?  Or, more probably, you wanted to add the function result but
> got it wrong?
>
> If you want to 'tostring' the elements, you can do it while adding
> them to the table, no need to retraverse the table later.
>
> -- Roberto
>
>

Ah, I see how the nil example was a bit of a red herring.

I have to admit I'm still unconvinced, though. They are both quite
similar ideas: when you call a table function you are expected not to
break the "contract" that the table should not have any holes, and
when you call table.concat() specifically, you are expected not to
break the "contract" that the table only contain strings. If it's OK
to not throw an error and return something the user might not be
expecting when the first "contract" is broken, it seems like it should
be just as OK for the second one. (Particularly since the second
mistake just seems so much less likely to happen in practice - your
example of forgetting to call the function just doesn't feel like
something that I fall into doing even at my most careless - but this
is a completely subjective observation, I know.)

-Duncan