-
-
Notifications
You must be signed in to change notification settings - Fork 6.8k
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
Add support for deserialization of STL containers of non-default constructable types (fixes #2574). #2576
Merged
nlohmann
merged 18 commits into
nlohmann:develop
from
AnthonyVH:non_default_constructable_stl_containers
Apr 25, 2021
Merged
Add support for deserialization of STL containers of non-default constructable types (fixes #2574). #2576
Changes from 1 commit
Commits
Show all changes
18 commits
Select commit
Hold shift + click to select a range
1e825e4
Add support for deserialization of STL containers of non-default cons…
AnthonyVH c0a8b45
Renamed template parameter and added some comments.
AnthonyVH 1b113f7
Added extra tests to improve coverage.
AnthonyVH 23f462b
Reduced code duplication, renamed tag to identity_tag.
AnthonyVH 672e8bf
Fixed std::pair trying to deserialize via array functions.
AnthonyVH 6ebf274
Add internal version of is_default_constructible to work around LWG 2…
AnthonyVH 6278f31
Simplify from_json overloads.
AnthonyVH 6ef1614
Refactor json::get() to use priority_tag.
AnthonyVH fc8c584
Regenerated single include.
AnthonyVH fbf6df6
Enable member function calls in trailing return decltype expressions …
AnthonyVH d7c0f15
Merged from_json for pair and tuple to try to fix C2995 error in old …
AnthonyVH 6eb37e9
Only add conditional constexpr to get() for >= C++14 to work around e…
AnthonyVH 848927a
Updated comments as requested.
AnthonyVH 130382f
Remove comment about GCC commit which didn't really relate to the code.
AnthonyVH 333612c
Merge remote-tracking branch 'upstream/develop' into non_default_cons…
AnthonyVH 322bc99
Reran amalgamate.
AnthonyVH 8e79917
Fix clang-tidy complaints.
AnthonyVH 2b86513
Fixing CI errors.
AnthonyVH File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is not how
priority_tag
is supposed to be used. You should have a singlefrom_json
overload and construct the tag with the highest value, like this:This gist shows quite nicely how to use it. Basically, it forces the overload resolution so you don't have to perform every SFINAE check in the world (like you had
is_default_constructible
and! is_default_constructible
)There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note that there's only 1 possible overload for
from_json_inplace_array_impl()
, hence 0 is the highest value in that case. Or am I missing something else?The
from_json_inplace_array_impl_base()
is there because there's noindex_sequence
argument forfrom_json_inplace_array_impl()
. I could add that and callmake_index_sequence()
fromfrom_json()
, but then any futurefrom_json_inplace_array_impl()
overload should have that as an argument as well, which didn't seem ideal. Hence the extra indirection.I also looked into making this part of the
from_json_array_impl()
overloads, but there's SFINAE on its "entry-point"from_json()
which prevents it from being called for non-default constructable types.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, it's me sorry. But in this case there is no need for
priority_tag
at all.Just thought about it but non-default constructible types can very well use
from_json(Json const&, T&)
overloads, this happens whenget_to
is used for instance.Therefore, the
is_default_constructible
check should just happen inget
, and all functions that default-construct values before callingJSONSerializer<T>::from_json
, no?This would allow you to dispatch to
from_json_array_impl
and then usepriority_tag
.It's been quite a while since I put my hands/eyes on the code, sorry for rusty review 😅
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
True, I didn't have that there originally, but I gathered from one of your previous comments that you preferred this to make adding future overloads easier. I can remove it again if you prefer.
Yes, that's true. Checking for default constructability in
detail::from_json
(e.g. the array version) shouldn't be necessary, since at that point you already have a reference to such an object, so it's already constructed.Note that
get()
already has some checks using e.g.has_from_json
andhas_non_default_from_json
. And those currently depend on default constructability of a type, since they depend the presence of certain signatures offrom_json
existing, and some of those in turn exist based on constructability of a type. Which as noted above actually isn't necessary...So I guess the solution would be to get rid of constructability checks in
from_json()
and add an explicitstd::is_default_constructible
toget()
?I can take a look at it later this week. Although that might be overextending the scope of this PR. Or is that not an issue?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When there is at least two overloads, yes 😄
I think it's a part of it, then you adding a
get
overload with that deals with non-default constructible types that do not havehas_non_default_from_json
should do the trick (it would check iffrom_json(json, identity_tag<>
is valid).Icing on the cake would be to refactor all those
get
overloads to usepriority_tag
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, I got ride of the redundant
priority_tag
and simplified some more code.The LWG 2367 but mentioned below should also be fixed. Let's see what the regression says.
Also added some icing 😉.