Please consider the following C++ snippet:
Obviously, this is a dereference of the pointer stored in the 13th location in
array. Or, wait, is it indexing 12 into an array pointed to by
array? While this is not ambigious in the normal sense of the word (i.e. - the standard has one clear answer to which one this is), it is confusing for programmers to read and write. The root cause here is that we apply two modifiers to
array, one is a prefix and the other a postfix. With no natural progression, we are left either remembering what the standard says (do you?) or employing trial and error.
The D language has already done away with this ambiguity where type are defined. The type modifiers progress linearly from left to right:
int a; // Signed 32 bit integer int b; // Array of size 16 of signed 32 bit integers int* c; // Pointer to array of size 16 of 32 bit integers.
Practical is definitely adopting that. I’ve worked with D for four years, and it was easy to get used to and far more intuitive.
While working on pointers, I started to ask myself whether it doesn’t make sense to do the same with the operators using during expression evaluations:
a // Whatever type a is a* // Whatever a was pointing at. *a in C a* // The 13th element in the array pointed to by a
Adopting this notation will also eliminate the need for many parenthesis. For example:
a*.member // In C we'd have to write (*a).member, or a->member
I should also point out that this syntax is more intuitive to read. The transformations the variable undertakes follow one another in natural reading order, with no jumping back and forth.
Which brings us to the “why not” part of this message. The only reason not to do this, at least as far as I can think of, is that it takes getting used to.
So, what do you think? Worth the non-standardizing?