HN2new | past | comments | ask | show | jobs | submitlogin

I really wish someone did a luajit fork with zero based indexing. It's even more galling in Luajit, because you can otherwise use native C types completely frictionlessly.


I'm on it... sometime. Some people have told me "That would be bad because you would lose all these awesome Lua libraries" but I think it's not such a big problem because Lua has no libraries, the FFI will still work, C will still be 0-indexed, and it's not too much work to convert a Lua library to use 0-based indexing.


I 100% agree. Lua is a small and elegant language, with two unambiguous severe flaws: global scope as default and one based indexing (one based indexing might be fine in other contexts, but not as some C/C++-glue language). The global scope thing can be mostly worked around with tooling, but the 1-based indexing (which in the context of luajit's seamless FFI and terra really means both 1 and 0-based indexing) adds so much friction that it's well worth giving up on or patching existing lua libraries.

Additionally, the lua ecosystem is already fractured (luajit is 5.1 + some selective ports of 5.2 stuff) and my feeling is that making this fracture complete will probably work out better in the longer run.


Nothing prevents you from just using [0].


I know that luajit is carefully written to make this fast as well, but it's of course nonsense that nothing prevents one from doing that. It breaks `#` for starters:

    #{[0]=1,2,3} == #{2,3} -- true
To be able to use zero-based indices ergonomically, the standard library and so one need adjusting as well.


Yes. I looked into consistently using [0] in the past, overriding `__len` and `__ipairs` etc, but kept running into corner cases that stopped it working robustly.

Despite how it may appear, 1-based indexing is quite fundamental to Lua.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: