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.
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
Add support for deserialization of STL containers of non-default constructable types (fixes #2574). #2576
Changes from 5 commits
1e825e4
c0a8b45
1b113f7
23f462b
672e8bf
6ebf274
6278f31
6ef1614
fc8c584
fbf6df6
d7c0f15
6eb37e9
848927a
130382f
333612c
322bc99
8e79917
2b86513
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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 😉.