I don't get why a language can't have both 0 and 1 based indexing, just set it as a compiler flag or something. They are a homomorphism, it's not hard to add or subtract one.
That sounds like it belongs in the top 10% of the worst (programming-related) things I could wish upon another programmer: Having to maintain projects where you have to read the build system's configuration and keep it in mental context just to figure out if an array access is mathematically correct or not.
I would imagine this support to be stomachable if it was active at all times but using a visually different syntax for 0-based and 1-based indexing, maybe using something like the guillemet for the latter (like this: «1») that is wild enough to draw the user's attention when reading the code, and not common/prominent enough across keyboard layouts to make most users think twice before using it when writing code unless it makes sense for the domain.
It's hard enough to understand a codebase, but if a language was like Haskell for instance (you can enable certain extensions in Haskell with a flag at the top of a file), you could have a line at the top of a file defining that this file is 0 based, while maybe the default is 1 based for the language. It doesn't seem like that much more than you already have to consider in many languages.
Funny you put it like that, because the fragmentation regarding language extensions is frequently discussed as one of the biggest issues affecting real world Haskell.
You can actually switch starting indices fairly easily in Fortran [1], or for that matter Julia, but for some reason the option doesn’t seem to be particularly widely used. People seem to give a lot of weight to the default, even when the effort to change is minimal. Added complexity/ambiguity?
You could declare the array as array[0..100] of something resp. array[1..100] of something for 0/1 based, and just as well do array[2..100] of something, or array[-1..100] of something, for -1/2 based.
Or with letters array['a'..'z'] of something,
Or with enums. TEnum = (red, blue, green), and then an array array[red..green] of something
This would all be fine until you start passing and returning these arrays and indexes between independently implemented functions and modules. Then you'd have to start declaring an index type tied to a specific array or a way to look up the index base for a passed in array.
Which would be fine actually for the program itself, if this is all figured out by the compiler/at runtime, though obviously more inefficient "for no good reason".
It would wreak havoc on the programming side though. Have you ever worked on a code base with more than a few people? Have you ever had to deal with different preferences programmers have? Differences in opinion between smart, slightly (or not so slightly) non-social people?
Using 0 or 1 indexed arrays, the new space vs tabs war! Or the new 2 spaces vs. 4 spaces vs. 8 spaces vs. using tabs war!
Ada lets you use any integer subtype as an array range. The first index can start anywhere you wish. It's string library defaults to 1-based but you can easily interoperate with strings using a different subtype. Code can be written that is base agnostic by using the attribute mechanism or by aliasing arrays to use a known range.
I remember some version of BASIC from the early 80's. You could create real multi-denominational arrays including sparse ones with any starting index(s) you wanted.
OK, thanks. I've not used that. The problem I had was that I learned Fortran before coming across BASIC, so converting Fortran programs was often a problem when features where missing.
I would imagine this support to be stomachable if it was active at all times but using a visually different syntax for 0-based and 1-based indexing, maybe using something like the guillemet for the latter (like this: «1») that is wild enough to draw the user's attention when reading the code, and not common/prominent enough across keyboard layouts to make most users think twice before using it when writing code unless it makes sense for the domain.