Why does C have a distinction between -> and .?

Question

OK, this is of no serious consequence, but it\'s been bugging me for a while: Is there a reason for the distinction between the -> and . operato

Answer 1

Yes, that's OK, but it is not what C really needs at all

Not only is it OK, but it is the modern style. Java and Go both just use .. Since everything that doesn't fit in a register is at some level a reference, the distinction between thing and pointer to thing is definitely a bit arbitrary, at least until you get to function calls.

The first evolutionary step was to make the dereference operator postfix, something dmr once implied he at some point prefered. Pascal does this, so it has p^.field. The only reason there even is a -> operator is because it's goofy to have to type (*p).field or p[0].field.

So yes, it would work. It would even be better as it works at a higher level of abstraction. One really should be able to make as many changes as possible without requiring downstream code to change, that's in a sense the entire point of higher level languages.

I have argued that using () for function calls and [] for array subscripting is wrong. Why not allow different implementations to export different abstractions?

But there isn't much reason to make the change. C programmers are unlikely to revolt over the lack of a syntactic sugar extension that saves one character in an expression and it would be hard to use anyway because it would not be immediately if ever universally adopted. Remember that when standards committees go rogue they end up preaching to empty rooms. They require the willing cooperation and agreement of the world's compiler developers.

What C really needs isn't ever-so-slightly faster ways to write unsafe code. I don't mind working in C, but project managers don't like having their reliability determined by their worst guy, and it's possible that what C really needs is a safe dialect, something like Cyclone, or perhaps something just like Go.