4 ms·

Will it still give the wrong answer if your table isn't sequentially indexed? That is, does #({[1]="a", [3]="b"}) return 1 or 2? edit: I see that it still ret

by ebg13 6y ago

Will it still give the wrong answer if your table isn't sequentially indexed? That is, does #({[1]="a", [3]="b"}) return 1 or 2? edit: I see that it still returns 1. That's a shame. This trips up so many newcomers who've been told that "#" means "length". IMO they need to either start calling it something other than the "length operator" or make it _actually_ return the length. Sadly at this point it would just be yet another breaking change.

anonymoushn 6y ago
1 or 3 but not 2 edit: yes, in fantasy-lua there will be an array type that can represent [1,nil,3] (sequence of 3 values)
- ufo 6y ago
  The ideal fix would to allow tables to store nil values, instead of always treating nil as a "hole". Instead of assigning nil to remove a value, you would call a separate "delete" function or operator. This way there would still be only one table type instead of separate types for tables and arrays. Some early alpha versions of Lua 5.4 played around with this idea but it turns out that it would break too many things. I'd expect that if Lua ever makes a major jump to Lua 6.0 then nils in tables will likely be one of the main changes.
  - anonymoushn 6y ago
    I'd like to read more about this. It would be a little unfortunate to end up with Python's "x in y" and "del y[x]" just to differentiate between missing entries and present entries set to nil. On the other hand, my not-very-well-considered preferred approach creates some asymmetry between arrays and maps as to what values can be stored. Or it perpetuates the existing asymmetry between varargs and tables...
    - pansa2 6y ago
      From http://lua-users.org/lists/lua-l/2018-03/msg00155.html http://lua-users.org/lists/lua-l/2018-03/msg00155.html. Looks like this was in the first pre-alpha release of 5.4 but removed shortly afterwards: > t[i]=undef is a special syntax form that means "remove the key 'i' from table 't'". You can only use 'undef' in three specific forms: t[i] = undef -- remove a key from a table t[i] == undef -- test whether a table has a key t[i] ~= undef -- test whether a table has a key
      - anonymoushn 6y ago
        Thanks! I like this proposal a lot.

by ebg13 6y ago

anonymoushn 6y ago

1 or 3 but not 2 edit: yes, in fantasy-lua there will be an array type that can represent [1,nil,3] (sequence of 3 values)

ufo 6y ago
The ideal fix would to allow tables to store nil values, instead of always treating nil as a "hole". Instead of assigning nil to remove a value, you would call a separate "delete" function or operator. This way there would still be only one table type instead of separate types for tables and arrays. Some early alpha versions of Lua 5.4 played around with this idea but it turns out that it would break too many things. I'd expect that if Lua ever makes a major jump to Lua 6.0 then nils in tables will likely be one of the main changes.
- anonymoushn 6y ago
  I'd like to read more about this. It would be a little unfortunate to end up with Python's "x in y" and "del y[x]" just to differentiate between missing entries and present entries set to nil. On the other hand, my not-very-well-considered preferred approach creates some asymmetry between arrays and maps as to what values can be stored. Or it perpetuates the existing asymmetry between varargs and tables...
  - pansa2 6y ago
    From http://lua-users.org/lists/lua-l/2018-03/msg00155.html http://lua-users.org/lists/lua-l/2018-03/msg00155.html. Looks like this was in the first pre-alpha release of 5.4 but removed shortly afterwards: > t[i]=undef is a special syntax form that means "remove the key 'i' from table 't'". You can only use 'undef' in three specific forms: t[i] = undef -- remove a key from a table t[i] == undef -- test whether a table has a key t[i] ~= undef -- test whether a table has a key
    - anonymoushn 6y ago
      Thanks! I like this proposal a lot.