title: Using public readonly fields for immutable structs instead of private field/public getter pairs
body: <p>This is my first time writing small immutable structs that will be used in extensive geometric calculations. I'm tempted to use <code>public readonly</code> fields instead of <code>private field/public getter</code> combinations.</p>
  
  <pre><code>public struct Vector4
  {
      public readonly float Angle, Velocity;
  
      // As opposed to:
      private float _Angle, _Velocity;
      public float Angle { get { return (this._Angle); } }
      public float Velocity { get { return (this._Velocity); } }
  
      public Vector4 (float angle, float velocity)
      {
          // Once set in the constructor, instance values will never change.
          this.Angle = angle;
          this.Velocity = velocity;
      }
  }
  </code></pre>
  
  <p>It looks a lot cleaner and eliminates an extra layer (the getter). Short of using public fields being bad practice, are there any negative implications to using public readonly fields this way?</p>
  
  <p>Note, we're talking about value types only. Arrays, for example would expose elements to be overwritten by calling code.</p>
  
  <p><strong>UPDATE:</strong></p>
  
  <p>Thanks for all the input. It seems that there is no downside to using <code>public readonly</code> fields for cases like this where data-binding, etc. is not used. In my benchmarks, execution time dropped by 70% which is a big deal. Targeting .NET 4, I would have expected the compiler to inline getter-only properties. The benchmarks were of course tested in release configuration without the debugger attached.</p>