I agree that if we could develop a version of optional that could be typedefed to C++17 optional in the future that could be an interesting win. I still hesitate to do this as the general use API though since it promotes the idea of null strings still. My current leaning is to only provide option 1 and promote all null strings to empty string. Then if it plays out that a null string actually is necessary we could add to the API geode::optional<std::string> readOptionalString(...) for those that want to support null string. While that does create a new API method I think I favor that over promoting null strings in a single API of geode::optional<std::string> readString(...) where all calls would have to check the optional for a value when in normal C++ there should always be a value for std::string.
-Jake On Wed, Dec 20, 2017 at 9:01 AM David Kimura <dkim...@pivotal.io> wrote: > 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 > > >
