On Fri, Mar 6, 2020 at 6:16 PM Diego Nehab wrote:
In other words, t[f()] is always a single-index access, even when f() returns multiple values.
IMO, that would make the whole proposal almost useless.
Do you think that accessing a multi-index table should only be done indirectly through a function that returns the multiple required indices? Or do you believe that this is would be the typical usage?
I don’t.
I get what Egor is trying to say here. Always narrowing functions to a single return value like that makes it a significant hassle to write functions that return an index into a multi-index table.
In my opinion, I think that the compatibility break would be worth it, especially if the default table lookup always disregards indices past the first, since that would minimize the breakage. However, see below...
The metamethods can do whatever they want with the '...'. The behavior is the same when there already exists an entry in the table with a single index, but there should never "already exist" a multi-index entry in a table.
Does it mean that
- t[i,j] will always invoke a metamethod,
- it's the programmer's task to save/load multi-index values somewhere by implementing some logic in __index/__newindex?
If that's true, then the whole proposal is absolutely useless.
It does solve exactly the problem it sets out to solve. It is the programmer’s job to define the metamethods for all userdata representing the types they need when writing the Lua bind of a library. How is this any different? There is no free lunch.
I see a couple of competing arguments here.
(1) It may be better to treat t[i,j] as being equivalent to t[i] in the absence of __index/__newindex. Combined with the above discussion about multi-return functions, this would be the most compatible with old code.
(2) Provide a meaningful default implementation for t[i,j] so that Lua has a multidimensional compound data type built in.
I don't think that it's "absolutely useless" without either of these as Egor asserts, but it's certainly inconvenient. At the very least, it would be nice if the table library provided a predefined multi-index metatable you could assign to a table, or a function that returns an empty table already configured with such a metatable.
/s/ Adam
