title: Optional fields and constraints in Protocol Buffers (protobuf) v3.0.0-alpha-2
body: <p>I am currently playing around with v3.0.0-alpha-2 of Google <a href="https://github.com/google/protobuf" rel="noreferrer">Protocol Buffers</a>.</p>
  
  <p>As far as I understand v3 removes the <code>required</code> keyword, the <code>extensions</code>
  keyword and default values for fields to simplify the proto language.</p>
  
  <p>What I <strong>do not</strong> understand is the meaning of the <code>optional</code> keyword in proto3.</p>
  
  <p><em>Example:</em></p>
  
  <pre><code>syntax = "proto3";
  
  package fw.example;
  
  message ExampleMessage {
    optional string optional_string = 1;
    string normal_string = 2;
  }
  </code></pre>
  
  <p><em>Question:</em> What is the difference between <code>optional_string</code> and <code>normal_string</code>
  besides the name and the tag?</p>
  
  <p>I've already read the following resources (they seem to be the only publicly
  available yet for v3 of protobuf):</p>
  
  <ul>
  <li><a href="https://github.com/google/protobuf/releases/tag/v3.0.0-alpha-2" rel="noreferrer">Protocol Buffers v3.0.0-alpha-2 Release Notes</a></li>
  <li><a href="https://developers.google.com/protocol-buffers/docs/proto3" rel="noreferrer">proto3 Language Guide</a></li>
  </ul>
  
  <p>But they do not even mention the <code>optional</code> keyword.</p>
  
  <ul>
  <li>Is <code>optional</code> obsolete in proto3, since a field is always optional?</li>
  <li>How can one enforce required fields with proto3 if <code>required</code> is gone?</li>
  </ul>
  
  <p>It seems that in proto3 one cannot longer distinguish between unset fields and
  fields set by a client to the (implicit) default value.</p>
  
  <p>Is the best practice to wrap each proto3 message in a language-specific class?
  I am using C++ and I need to ensure that specific fields are set. It seems that
  validation has to be done manually in language-specific source code now, in
  contrast to proto2.</p>
  
  <p>Can someone enlighten me, what's the best approach to apply constraints on a
  proto3 message but allow scheme evolution? At the moment I think that a new API
  has to be written around the proto3 messages, so that a client does not deal
  directly with the proto3 generated code, but with the custom API code. Is that
  correct?</p>
  
  <p>Maybe someone can show me a concrete example to discuss about.</p>
  
  <p>I am pretty confused, since the following is stated in the release notes of v3:</p>
  
  <blockquote>
    <p>We recommend that new Protocol Buffers users use proto3. However, we do not
    generally recommend that existing users migrate from proto2 from proto3 due to
    API incompatibility, and we will continue to support proto2 for a long time.</p>
  </blockquote>
  
  <p>If proto3 is the way-to-go, why are things complicated? It seems to me that I do need to write a lot more code than with proto2 now.</p>