Skip to content
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

P0935R0 Eradicating Unnecessarily Explicit Default Constructors #41

Closed
StephanTLavavej opened this issue Sep 6, 2019 · 7 comments · Fixed by #415
Closed

P0935R0 Eradicating Unnecessarily Explicit Default Constructors #41

StephanTLavavej opened this issue Sep 6, 2019 · 7 comments · Fixed by #415
Labels
cxx20 C++20 feature fixed Something works now, yay!
Milestone

Comments

@StephanTLavavej
Copy link
Member

P0935R0 Eradicating Unnecessarily Explicit Default Constructors

@StephanTLavavej StephanTLavavej added the cxx20 C++20 feature label Sep 6, 2019
@NathanSWard
Copy link
Contributor

This sounds like a good next issue I can tackle.
This seems similar to #69 where I'll provide the _HAS_CXX20 block with the new non-explicit constructor and the constructor with the non-default parameter.

@StephanTLavavej
Copy link
Member Author

I wonder whether we should implement this unconditionally. Implementers have long-standing permission from the Standard to implement member functions (including constructors) with different signatures than depicted, as long as the behavior is the same. Splitting up default arguments into separate overloads is an allowed transformation.

Unconditional implementation would be unlikely to disrupt 14/17 code, since making a default constructor implicit has basically no effect for someone who didn’t need it. The downside would be portability - users might take advantage of it, and then have problems porting to other STLs.

So perhaps the best thing to do would be to unconditionally split signatures, but then mark the default constructor with an _EXPLICIT_BEFORE_20 macro, avoiding as much code duplication as possible.

@BillyONeal, @CaseyCarter, @barcharcraz - thoughts?

@CaseyCarter
Copy link
Member

Mild preference for _EXPLICIT_BEFORE_20 for portability. We should probably back-channel a consensus with libc++ and libstdc++, however: if they implement unconditionally and we do not, we may end up hampering rather than helping portability.

@BillyONeal
Copy link
Member

Mild preference to treat it as a DR. (And admonish lib(std)?c++ to do the same)

@StephanTLavavej
Copy link
Member Author

I've emailed some libc++ and libstdc++ maintainers about implementing this unconditionally.

@StephanTLavavej
Copy link
Member Author

libstdc++ has implemented this unconditionally, so we should do the same thing - no macros or preprocessor logic. (We have an "implemented unconditionally" section in yvals_core.h.)

@NathanSWard
Copy link
Contributor

@StephanTLavavej thanks for following up with the other library vendors! An unconditional implementation it is!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cxx20 C++20 feature fixed Something works now, yay!
Projects
No open projects
Development

Successfully merging a pull request may close this issue.

5 participants