maps with integer keys can be confusing about lua-protobuf

[seabadger]

Correction: looks like all keys are accessible with pairs(), and only non-negative are accessible via ipairs().

So this is only a little inconsistent, and may catch people if they either try to access the data using ipairs(), or if they try to use something that accesses tables in a generic way (e.g., the output above was produced via https://github.com/kikito/inspect.lua).

Thus, maybe not a bug, but a possible usability problem. I understand you may want to keep it the way it is, but I'll keep the report open just in case you have other thoughts.

[starwing]

Thanks for catching! But it’s really a bug. I will fix on next push (maybe tonight)

[starwing]

After a carefully review code and review your post, I'm very sorry I misunderstand your issue before :-(

Yes, it's not a bug. in Lua, { "one", "two" } is exactly just { [1] = "one", [2] = "two" }, and former is just a syntax sugar of latter.

and map's semantics indicate no order. means { [1] = "one", [2] = "two" } or { [2] = "two", [1] = "one" } are all legal result of decode.

[starwing]

Notice that's the semantics of Lua language. So I have no way to change this behavior :-)

just close, if you have new idea about map, you can re-open it. Thanks for feedback!

[seabadger]

I agree that this is semantics of Lua and not really a bug (thanks for taking a look anyway! :).
It might still be worth mentioning this in the documentation that map keys, even when they are integers, should be accessed via 'pairs()' only, not ipairs() (since the latter might not give the full set of keys). I know it's just the language semantics, but it's one of the less obvious bits that might catch someone.

[starwing]

Okay I will change document :-)