Re: pairs(t, skey) and ipairs(t, skey)

[Tim Hill <drtimhill@...>]

On Oct 3, 2013, at 6:29 AM, Roberto Ierusalimschy <roberto@inf.puc-rio.br> wrote:

>> Present behavior:
>> With a sequence: # returns valid length
>> Without a sequence: # returns arbitrary integer value that is easy to mistake for a length
>> 
>> Suggested behavior:
>> With a sequence: # returns valid length
>> Without a sequence: # returns nil
>> 
>> Why is the suggested behavior bad?
> 
> Two possible reasons that deserve more thought:
> 
> - Performance. Every assignment to an integer key has to check whether
> it is keeping/breaking a sequence. (If you add n elements to a table,
> the accumulated overhead of these checks is O(n), just like any other
> check for table sequenceness.) Even the majority of programs that do not
> need such thing will pay for it.

Agreed. My suggested implementation (in this thread) has some additional overhead that is O(n); a couple of simple tests which a decent compiler would boil down to a very tight bit of code. We're talking nanoseconds per element on an x86 here.

> 
> - Reasoning. The proposed behavior can be as baffling as the current
> one.  ("Why is this table not a sequence??") For instance, every
> algorithm that manipulates a sequence (e.g., sorting methods) will have
> to be carefully checked to see whether it can assign a nil temporarily
> in the middle of a sequence.

My argument has been less about baffling than about the bafflement being hidden. At present, # can return values that can *appear* be to valid but are in fact not, something that can mask bugs.

> 
> -- Roberto
>