Re: hpairs?

[Roberto Ierusalimschy <roberto@...>]

> > It uses the fact that 'next' first traverses array part and then
> > hash part. Massive, but should be fast for rehashed tables.
> 
> This sort of behavior will be banned, period, once my Evil Overlord
> credentials have been suitably established.  Seriously:
> 
>   *****
>   The order in which the indices are enumerated is not specified, even
>   for numeric indices.
>   *****
> 
> Don't 'use the fact' that a certain implementation happens to be put
> together a certain way and start relying on it for correctness.

Even in the current implementation that is wrong, because the numeric
indices not necessarily live in the array part of the table.  The next
program lists a, 2, c, b, e, d, 3, 1 in my machine. (Results may vary.)

  a = {a=1,b=2,c=3,d=5,e=6}
  a[1] = 1
  a[2] = 1
  a[3] = 1
  
  for k in pairs(a) do print(k) end



> But really I'd tend to just avoid having hpairs/ipairs in the first
> place and if I'm going to make a bipartite table avoid storing any
> values at numeric keys that don't fall into the array-esque part, then
> filter on the 'number' type.  There's a couple of reasons I can
> imagine for iterating all the non-ipairs keys, but most of them are
> rather specialized and would have an ipairs right next to them anyway.

Very well said.

-- Roberto