title: Attaching a "policy" to a function parameter
body: <p>In some code that I am writing, I have a bunch of C++ functions that I am trying to bind to lua in a generic way. (However, this question really has nothing to do with lua, it's really a C++ design question.)</p>
  
  <p>The idea is I might have a C++ function with signature</p>
  
  <pre><code>int my_function(lua_State * L, std::string server, std::string message);
  </code></pre>
  
  <p>for instance, and I want to be able to push it to lua and expose it to user scripts.</p>
  
  <p>However, lua can only directly receive functions of signature <code>int (lua_State *)</code>. So, I have some templates which take a function pointer with signature like the above, and produce a function of signature <code>int(lua_State *)</code>, which tries to read corresponding arguments off of the lua stack, and calls the target function with the parameters if it succeeds, and signals a lua error for the user if not.</p>
  
  <p>That part is working, with some work, and this question is not about how to do that. (Please don't tell me about <code>luabind</code>, <code>luabridge</code> or other existing libs, for reasons I can't go into those are not appropriate for my project.)</p>
  
  <p>Instead the issue I'm having now is that sometimes I want the input parameters to have slightly different semantics.</p>
  
  <p>For instance, sometimes a parameter should be optional. I specialized my template for <code>boost::optional</code> in order to handle that case. So I can tag optional parameters with <code>boost::optional</code> in the function signature and the wrapper will know that if that parameter is missing, it's not an error, and it should just pass <code>boost::none</code>. Example:</p>
  
  <pre><code>int my_function(lua_State * L, boost::optional&lt;std::string&gt;, std::string message);
  </code></pre>
  
  <p>So the <code>boost::optional</code> template is being used kind of like a "policy" for the input here, and I basically like how that is working.</p>
  
  <p>Here's an issue I'm less sure about though: handling of <code>bool</code>. In lua, there is a proper <code>boolean</code> type, however, lua also has a notion of <code>contextually boolean</code>, similar to C++'s notion of <code>contextually convertible to bool</code>. In lua, the values <code>false</code> and <code>nil</code> are falsy, and all other values are truthy.</p>
  
  <p>Typically, when you have a c++ function that takes a <code>bool</code>, the user will expect that they can pass it any value and that your interface will respect the <code>truthiness</code> even if it's not strictly speaking a boolean value. However, in other cases, you might really want it to be interpretted strictly as a <code>bool</code>, and for it to be a user error if they don't pass <code>true</code> or <code>false</code>.</p>
  
  <p>What I would like to be able to do is tag the "strictness" policy within the function declaration, so it would look like</p>
  
  <pre><code>int my_function(lua_State * L, strict&lt;bool&gt; b, std::string message);
  </code></pre>
  
  <p>Where, <code>strict</code> is some template like</p>
  
  <pre><code>template &lt;typename T&gt;
  struct strict {
    T value;
  };
  </code></pre>
  
  <p>and this template really has meaning only in my wrapper machinery.</p>
  
  <p>The thing that is annoying about this is that then you have to type <code>b.value</code> everywhere.</p>
  
  <p>I thought about doing it like this:</p>
  
  <pre><code>template &lt;typename T&gt;
  struct strict {
    T value;
  
    operator T &amp; () &amp; { return this-&gt;value; }
    operator const T &amp; () const &amp; { return this-&gt;value; }
    operator T &amp;&amp; () &amp;&amp; { return std::move(this-&gt;value); }
  };
  </code></pre>
  
  <p>to allow a bunch of ref-qualified implicit conversions from <code>strict&lt;T&gt;</code> to references to the value.</p>
  
  <p>How unsafe is this? I don't see major safety holes in this, although I've always adhered to the "implicit conversions are evil" mantra. I played around with it a little in test code and it doesn't seem to create ambiguities or problems, but there might be a clever way to make this do something very bad that I didn't think of.</p>
  
  <p>If it's not a good idea, is there a better strategy than typing <code>b.value</code> everywhere, or some different way of rigging up the parameter policies that won't intrude upon the types?</p>