What colour do you want your bikeshed painted today?
I for one, don't like the "->" operator in C. It requires two characters and the use of the shift key. I would like that the next standard just used "." for all member access and let the compiler work its magic and guess what needs to be done.
Of course that would break a sizeable amount of legacy code, but who cares about that anyway. The important is that the code looks good, especially if I enable drop shadows and anisotropic filtering in my editor.
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 :)
I know you're being sarcastic, but since you bring it up, I think the -> operator in C(++) is awkward as heck. If dereferencing were a suffix operation as in Pascal, you could simply write p.foo instead of (p).foo.
I guess it'd break because of (a* +b) but that's just all the more reason to disallow whitespace around infix operators.
I for one, don't like the "->" operator in C. It requires two characters and the use of the shift key. I would like that the next standard just used "." for all member access and let the compiler work its magic and guess what needs to be done.
Of course that would break a sizeable amount of legacy code, but who cares about that anyway. The important is that the code looks good, especially if I enable drop shadows and anisotropic filtering in my editor.