31 ms·
So in Lua the "first" element has an index of 1. There's absolutely nothing wrong with this. And most people who haven't already been exposed to C and related
by rleigh 3y ago
So in Lua the "first" element has an index of 1. There's absolutely nothing wrong with this. And most people who haven't already been exposed to C and related languages would find this perfectly natural. Because it's an index number, not an offset.
It's only in C and C++ where the memory location of an element can be expressed as base+offset that we end up using the offset rather than an index. That has clear logic behind it and absent optimising compilers it may be marginally more efficient, but it does not make for the most user-friendly interface--it does break the expectations of most other people.
If I'm working on providing a Lua library interface for non-developers, they will find the default Lua behaviour far more natural than were I to force zero-based indexing upon them.
- Someone 3y ago> So in Lua the "first" element has an index of 1. There's absolutely nothing wrong with this. I’m beginning to wonder whether a language that doesn’t have indexes at all would be viable. Swift abandoned C-style for loops (https://github.com/apple/swift-evolution/blob/main/proposals/0007-remove-c-style-for-loops.md https://github.com/apple/swift-evolution/blob/main/proposals...) It still has enumerated (https://developer.apple.com/documentation/swift/sequence/enumerated https://developer.apple.com/documentation/swift/sequence/enu...()), though. That’s a special case of zip, though, and programs could use zip(items, 0...Int.max) or zip(items, 1...Int.max) according to their preference. Also, slices could be created using items.subrange( skip: 3, take: 5) instead of items.subrange( startIndex: 3, numItems: 5) Implementation-wise, those are identical, but conceptually, the first doesn’t use indexes