John Colvin:
Any reason why this needs language support? I haven't tried it, but I can't see why it can't be trivially done in a library.
I don't yet know the answer. I have to think more about the topic, and to try to implement something in library code. And then I can judge (a bit) if the result is good enough.
In D there are things that can be implemented well enough in library code (tensors). And we don't yet know if other things can be implemented well enough in D library code (like Typedef, or Algebric: http://forum.dlang.org/thread/[email protected] Currently Algebraic is not acceptable). And then there are things that now we know cannot be implemented acceptably well in D library code (like Phobos tuples, that lack essential features like unpacking in some different contexts. See Rust for an example of simple and reasonably designed built-in tuples: http://rustbyexample.github.io/examples/tuples/README.html ).
For D programmers to invest in the usage of (optionally) strongly typed array indexing in their medium-integrity D programs (you can avoid using that indexing style in script-like D programs), such feature has to return them some valuable advantages. This means this feature should increase compile-time safety and offer a rich enough semantics. Otherwise it's a waste of time for the people that implement it, because D programmers (rightfully) will not use it.
If you look at Ada, where this feature is more developed, you see some semantics that could be not so trivial to reproduce in D library code.
Time ago I have suggested to add to D "enum preconditions" that in theory can be used in library code to better implement some of the static semantics of similar data structures.
Bye, bearophile
