-
-
Notifications
You must be signed in to change notification settings - Fork 6.7k
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
Disable implicit conversions from json to std::initializer_list<T> for any T #1118
Comments
Can you give an example for this? |
The code snippet in #1116 demonstrates the issue. The assignment case can be mitigated with SFINAE in most cases (for the specific vector case we can't "fix" the constructor case since vector has the "explicit vector(size_t)" ...)
|
I'm quite against such a change, even if The change would fix vector I agree, but it's a coincidence that there is no other Especially if we decide to follow #958, this will make it harder for users to transition to I have a huge bias because of #958 though :p |
Correct, this would be a band aid, not a complete and universal solution. But it should be an effective band aid for the common cases (standard containers) Is your concern that by mitigating some of the practical issues with implicit conversions we'd weaken the rationale for a more radical change (like the ones proposed in #958 and #1116) ? |
Exactly. That's not my decision to make however, I think I have expressed my opinion enough already, so I'll follow along the final decision anyway. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
This is a cherry pick for from #1116: I suspect most ambiguities related to implicit conversions from json to standard containers (and not only) can be avoided by expanding the SFINAE around basic_json::operator ValueType() to explicitly exclude conversions to any std::initializer_list specialization.
It should be an quick, easy and safe fix (even if it doesn't fully address the full range of issues described in #1116). I'd be happy to prepare a patch if it helps.
The text was updated successfully, but these errors were encountered: