Given that C++17 is feature-complete, it seems prudent to adopt those patterns as much as possible.
My fear with #4 is that we're introducing a special case API that users become accustomed to and then unwilling to later switch to std::optional. And then we'd end up supporting multiple ways to do the same thing. And even if we can delete the special case API after C++17, there's still API churn for our users. Because of that, I favor using optional even if we have to roll our own. And then after C++17 we change our implementation to alias std::optional and there shouldn't be any code changes required from user point of view. Thanks, David On Tue, Dec 19, 2017 at 2:30 PM, Jacob Barrett <jbarr...@pivotal.io> wrote: > On Tue, Dec 19, 2017 at 1:52 PM Michael William Dodge <mdo...@pivotal.io> > wrote: > > > Of those, #1 seems better than #2 and #3. Is there an elegant way to use > a > > sentinel value of std::string to represent null, e.g., static const > > PdxReader::NULL_STRING = <magic happens here>? > > > > I am absolutely opposed to sentinel values just from the standpoint that > once you pick a value someone will want that value. > > The C++17 solution to this problem is std::optional<std::string>, but > unfortunately C++11 is our minimum. We could embrace boost::optional (for > which C++17 std::optional derives), but this will cause clients to also > depend on boost, which isn't ideal. We could roll our own optional... > > -Jake >
