-
-
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
Adding Structured Binding Support #1388
Comments
I agree this would be nice to have, you should consider opening a PR :) A few remarks: I do not see why a new namespace is needed. About the access level, there is no need to change it, |
No the issue is not with get.
I had a feeling there might have been some reason why it was kept private and hence wanted to discuss and confirm the same. Thank you so much for pointing out that the namespaces were unnecessary. If it's okay with you @theodelrieu I am going to edit the main comment to recognise the code that does not anymore require the namespaces and put the get within the class. |
I'm just guessing right now, did not play with structured bindings yet. But I think this should not be as hard to implement |
@theodelrieu while iterator_proxy is a very nicely implemented class, one of the issues it again faces is that all it does is returns the begin and the end. The key and the value are present in Also for example let us write the code
In this scenario, elem will be of the type iterator_proxy_internal which means it is somewhat getting exposed( or so Visual Studio/EDG tells me) Coming back to key and value, those are the two most important facets regarding structured bindings. However while discussing with you I had a Eureka moment and I am still confused why I did not think about it before
This leaks the code out and makes it available for tuple_size and tuple_element. As this stands, especially with the lack of requirement to drop Private, would this be good enough to make a PR Request?? |
I agree that having Plus, the API is exposed, only the name is not, which can always be retrieved via
Yup, I think we're good to go :) |
@theodelrieu I seem to be facing some issue struct tuple_element<N, nlohmann::detail::iteration_proxynlohmann::json::iterator::iteration_proxy_internal> See when I am modifying the Multiple Include files, I decided to place the get functions where they should have been in iterators/iteration_proxy.hpp However, the std function have a further requirement of needing the parameter nlohmann::json::iterator Or is there some template magic you know? |
You could forward declare it, or simply partially specialize: namespace std {
template <typename T, std::size_t N>
struct tuple_element<N, nlohmann::detail::iteration_proxy<T>>{ /* ... */ };
} |
No that was the first thing I tried. |
Describe the feature in as much detail as possible.
Given the fact that the Json Library now implements
items()
function, utilising Structured Bindings in this scenario would make the code much more simpler, easier to read and understandEven though Structured Bindings were added in C++17, the components/engines which ensure it exists are present in C++11 and C++14 and adding support would not require any
#ifdef
Include sample usage where appropriate.
A Sample usage of Structured Binding is
The reason I am writing it as an issue rather than as a pull request is because it makes one questionable change.
Most of the implementation is referenced from TartanLlama's Blog
In the Class
iteration_proxy_internal
we would have to add the function get for Structured Bindings Support.Thanks for @theodelrieu 's recommendations which helped shorten the code
This is not a major change and would cause no incompatibility.
Adding support for Structured Bindings however involves minor editing of the std namespace which may or may not be favoured by a few projects.
This is where we face an issue.
In both these methods, iteration_proxy_internal needs to be accessible.
However, as we know, iterator_proxy_internal is defined as a
private
method in theiterator_proxy
class.Hence in order to add support for Structured Bindings, we would have to either make it public, find a hack or use something similar to
friend
This is also the reason I decided to submit it as an issue rather than make a pull request.
I apologise for any and all mistakes committed by me while writing this.
I am quite new to GitHub and this is one of my first feature requests on a project
EDIT: Thanks to @theodelrieu for making recommendations which helped shorten the code
The text was updated successfully, but these errors were encountered: