title: Why does C have a distinction between -> and .?
body: <p>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 <code>-&gt;</code> and <code>.</code> operators?</p>
  
  <p>Of course, the current rule is that <code>.</code> acts on a struct, and <code>-&gt;</code> acts on
  a pointer-to-struct (or union).  But here's how it works in practice.
  Let <code>s</code> be a struct incuding an element <code>x</code>, and let <code>ps</code> be a pointer to a struct of the same form.</p>
  
  <p>If you write</p>
  
  <pre><code>s-&gt;x
  </code></pre>
  
  <p>the compiler will spit out a warning in the way of</p>
  
  <blockquote>
    <p>You meant s.x. Please retype that and recompile.</p>
  </blockquote>
  
  <p>If you write</p>
  
  <pre><code>ps.x
  </code></pre>
  
  <p>the compiler will spit out a warning in the way of</p>
  
  <blockquote>
    <p>You meant ps->x. Please retype that and recompile.</p>
  </blockquote>
  
  <p>Because the compiler knows the type of both <code>s</code> and <code>ps</code> at compile time, it has all the information it needs to interpret what the correct operator would be. I suspect that this isn't like other warnings (like a missing semicolon), in that there is no ambiguity about the correct fix.</p>
  
  <p>So here's a hypothetical proposal to the C1x standards committee (that would never be considered, because the ISO is on a conservative streak):</p>
  
  <blockquote>
    <p>Given the expression lhs.rhs, if lhs is a struct or union type,
        then the expression shall refer to the element of lhs named rhs.
        If lhs is of type pointer-to-struct or -union, then this shall be
        interpreted as (*lhs).rhs.</p>
  </blockquote>
  
  <p>This would certainly save us all time, and make it easier for people to learn C [and I've taught enough C to say with authority that learners find the <code>-&gt;</code> thing to be either confusing or annoying.] </p>
  
  <p>There's even precedent, where C does a handful of similar things.  E.g., for implementation reasons, function declarations are always cast to pointer-to-function, so <code>f(x,y)</code> and <code>(*f)(x,y)</code> will both work regardless of whether <code>f</code> was declared as a function or a pointer to function.</p>
  
  <p>So, my question: what's wrong with this proposal? Can you think of examples where there would be fatal ambiguity between <code>ps.x</code> and <code>s.x</code>, or why keeping the mandatory distinction is otherwise useful?</p>