-
Notifications
You must be signed in to change notification settings - Fork 92
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
if_contains
currently returns value*
, but it'd be better if it returned optional<value&>
#880
Comments
Well it would have to return |
Yeah, it also would have to be |
I'm not opposed, but there is the issue of invalidating user code. |
Theoretically you could return a type like: namespace boost::json {
template <typename T>
struct optional : boost::optional<T&> {
operator T*() const;
};
} which would preserve the But I dunno, seems worth breaking that code to give people a better API. Or you could just provide this other version under a different name. Like |
I like better ergonomics. Dmitry can you perhaps do an internet and a smart GitHub search to get an idea of how many people are using it? |
I can try |
I've discovered these projects that currently use JSON's
Ironically, most use |
As someone who uses this library but in general is trying to minimize boost dependencies, can I ask for such a change to allow for opt-in/opt-out through a preprocessor define or similar? Compile-time overhead is my main reason for this - I'm using FWIW, I'll add that I have no issue with breaking changes. The library is still young so I'd agree that breaking changes are preferable to workarounds. |
Dependency on Optional would also add dependency on Detail, Utility, Preprocessor, and Io. All fairly small libraries. If we go with this, we will not add a config option to choose optional implementation. Things like that are a constant source of headache for both users and maintainers, because people keep building libraries with one configuration and linking to it with another, which get them linking errors they have no idea how to fix. |
I've been broadly interested in using
I had a change accepted to the cxxopts library along similar lines in |
There is a call for GSOC '24 mentors on the boost mailing list. If this sort of "C++17 enrichment" project for boost::json is of interest to the maintainers, I'd be willing to propose, mentor and co-ordinate the work with input from the boost::json people. I've also thought about std::expected for the error-code path in boost::json as possibly being a nice thing in C++23 mode. |
While I'm here rambling about |
I have a WIP branch (locally) that adds accessor functions that return Why add? I decided that changing all of the pointer-returning functions would be too much of a change. Maybe it would have been a good idea initially (and Boost.URL did in fact go with it), but for JSON this ship has sailed. Why |
I would definitely make use of an API using |
No. The problem with such macros is that it effectively creates two different and API-incompatible libraries. |
#941 adds accessor functions that return |
Currently,
json::object
providesif_contains
that returns ajson::value*
(orjson::value const*
). This is a useful API, definitely more ergonomic than having to callfind()
and check againstend()
.However, it could be more ergonomic still.
boost::optional
actually supports references, andboost::optional<value&>
is a much more appropriate type here thanvalue*
. For simple uses, they're the same:But returning
optional
allows you to chain further operations and more conveniently access that underlying value. Like, say:optional
enables this approach, whereas with pointers you'd have to do something like:This pretty quickly gets more and more clunky. And then here's a bunch more reasons to prefer
optional<value&>
here.In short, even if you don't care much for the continuation style,
optional<value&>
supports all the existing valid uses ofvalue*
that exist today, doesn't support any of the existing invalid uses (likedelete
-ing the pointer, indexing the pointer, incrementing the pointer, ...), and supports more useful operations that do regularly come up (likemap
,and_then
,value_or
, ...)The text was updated successfully, but these errors were encountered: