if you want that, use a higher level language. One of the foundations of C is that there is as little implicit behavior as possible. I'd hate to be left in the dark whether my . will now result in a pointer or a dereferenced value and I doubt it would even work for the compiler to figure this out in all edge cases.
C is full of implicit type conversions. I think the key is that C is based on value semantics and not references, and that makes pointers full-blown values with their own address, conversions, … - something closer to C's integer types than to other languages' references, and equally picky about operators.
The C type conversions I know of seem quite trivial. Can you give an example of something non-trivial? And I don't mean something like the float f = some_integer / some_other_integer trap, those should be obvious.
The automatic dereferencing in "pointerToStruct.foo" might have to loop until it arrives at a struct. I think such a loop would be unique in C, but I don't feel it'd make C any higher level.
Similar in concept: &function and function are the same. If you have a fixed-size array: ary, &ary and ary[0] are the same when passing them into a function.
Then there are all the other numeric conversions, where "unsigned" is a common trap, and truthiness.
Even if most conversions are trivial, I wouldn't call C a very explicit language. Compared to what?
pointerToStruct.foo would just be equivalent to pointerToStruct->foo. No loop required.
The main problem with this is that it hides memory accesses. The offset of x.y.z.w relative to &x can be determined at compile time, so if &x is available, accessing x.y.z.w requires roughly only one load instruction. (DISCLAIMER: ABI- and compiler-dependent. One instruction is an estimate. This estimate may not be precisely true for all possible programs across all CPUs and compilers.) But x->y->z->w requires 3 pointer dereferences, even if you have x to hand. 3 load instructions and therefore 3 memory accesses. (The same disclaimer applies.) People already complain enough about the inefficiency of C++ operator overloading, and the difficulty of spotting when it occurs just by examination of the source code...
Additionally, this change wouldn't play nicely with C++ operator overloading.
I just set up my text editors to insert -> when I press <Alt-,>.
I assumed that arbitrary levels of indirection would be flattened, hence a loop. I'm not asking for this feature, I'm only arguing that C was never explicit to begin with.
For example, you cannot tell how many indirections happen in a[5][2][8] either. Every game programmer must have seen a newbie try to cast a[4][4] into a :)
if you want that, use a higher level language. One of the foundations of C is that there is as little implicit behavior as possible. I'd hate to be left in the dark whether my . will now result in a pointer or a dereferenced value and I doubt it would even work for the compiler to figure this out in all edge cases.