Yay to that!!
From my perspective, the main reason in favour of 1-based is that programmers almost universally write
let f (x1, x2) = ...
today, so the 1-based convention already is everywhere. IME it's quite confusing when such code is mixed with uses of a projection operator based on a different numbering scheme, which is inevitable in practice.
The comparison with arrays is less important IMO, since tuple indices are just static names and not computed, so rather different beasts.
That said, I don’t have a super-strong opinion here, just give me e.i already. :)
Cheers, /Andreas
On 25. Oct 2025, at 14:32, Gabriel Scherer gabriel.scherer@inria.fr wrote:
Dear SML people,
There is an OCaml feature proposal by Alistair O'Brien that would finally introduce tuple indexing in OCaml -- we currently have only whole-tuple pattern matching:
RFC: https://github.com/johnyob/ocaml-RFCs/blob/tuple-projections/rfcs/tuple_proj... discussion: https://github.com/ocaml/RFCs/pull/57
Of course this raises the Very Important Question of whether indexing should be 0-based or 1-based.
The argument in favor of 0-based is that it is what we use for arrays, so more consistent, standard in most programming languages. The argument in favor of 1-based is that it is arguably more intuitive (but the inconsistency with arrays weakens this claim noticeably), and that SML uses it.
Question: you have a lot more experience using tuple indexing. In your opinion, if this was to be decided again for a new system (no backward-compatibility concerns), would you still recommend using 1-based indices, or would you be more in favor of 0-based indices?
P.S.: You may be amused to learn that OCaml recently introduced "labeled tuples" (looking like `(x:1, y:2)` in expressions and `(x:int * y:int)` in types), which are basically a restricted version of SML structural records -- type inference does not try very hard and requires an annotation in practice.
P.P.S: Is there still a mailing-list for the SML/NJ crowd? All I could find were github discussions (https://github.com/orgs/smlnj/discussions) and an invite-only Zulip.