This is an archive of the discontinued LLVM Phabricator instance.

[libc++] [P0935] [C++20] Eradicating unnecessarily explicit default constructors from the standard library.
ClosedPublic

Authored by curdeius on Nov 11 2020, 12:25 PM.

Diff Detail

Event Timeline

curdeius created this revision.Nov 11 2020, 12:25 PM
Herald added a project: Restricted Project. · View Herald TranscriptNov 11 2020, 12:25 PM
Herald added a reviewer: Restricted Project. · View Herald Transcript
curdeius requested review of this revision.Nov 11 2020, 12:25 PM
curdeius added inline comments.Nov 11 2020, 12:27 PM
libcxx/include/random
101–103

Please disregard modifications to stuff other than linear_congruential_engine.

curdeius updated this revision to Diff 304732.Nov 12 2020, 12:03 AM
  • Clean up. Test default seed.

This is the same as D60422, which hasn't been updated in a while. I left some comments regarding how I suggest we create shared code to check for implicit default constructibility in that review. But I like the make_implicit<E>() trick.

@zoecarver I think you two should coordinate.

curdeius planned changes to this revision.Nov 19 2020, 11:26 PM
curdeius updated this revision to Diff 308553.Dec 1 2020, 12:04 AM
  • Implement: [rand.device] [rand.eng] [rand.dist.uni.int] [rand.dist.uni.real]

@ldionne, 've discussed it with @zoecarver, and we decided that I'll take it over. It might take some time as there are many things to change (and test), but I'll appreciate your feedback.

My doubts:

  • is using make_implicit really necessary or just test_convertible is enough? Using make_implicit tests as well that the default parameter is the correct one. It's not always possible (as in random_device for instance).
  • name and location of make_implicit?
  • I added as well test for ctors being explicit, and that was not tested before.

One more question, lots of stuff in <random> tests are also run in c++03. Is it expected? Should I add guards to my additions (#if TEST_STD_VER >= 11)?

curdeius updated this revision to Diff 308633.Dec 1 2020, 6:22 AM
  • Use typedef for C++03 compatibility.
  • [rand.dist.bern]
  • [rand.dist.pois]
  • [rand.dist.norm]
  • [stringbuf]
  • [istringstream]
  • [stringbuf]
  • [ostringstream]
  • [stringstream]
  • [re.results]
  • [depr.strstreambuf]
  • [depr.conversions.string]
  • [depr.conversions.buffer]
  • [queue] [priority.queue]
  • [stack]
curdeius updated this revision to Diff 308646.Dec 1 2020, 6:52 AM
  • Fix [rand] in C++03 mode.
curdeius edited the summary of this revision. (Show Details)Dec 1 2020, 8:20 AM

@ldionne, 've discussed it with @zoecarver, and we decided that I'll take it over. It might take some time as there are many things to change (and test), but I'll appreciate your feedback.

My doubts:

  • is using make_implicit really necessary or just test_convertible is enough? Using make_implicit tests as well that the default parameter is the correct one. It's not always possible (as in random_device for instance).

I think we should test the value of the default argument when we can, as you did.

  • name and location of make_implicit?

What you have looks OK to me.

  • I added as well test for ctors being explicit, and that was not tested before.

Thank you!

One more question, lots of stuff in <random> tests are also run in c++03. Is it expected? Should I add guards to my additions (#if TEST_STD_VER >= 11)?

We support <random> in C++03. It's one of those great things :-).

libcxx/test/support/make_implicit.h
25 ↗(On Diff #308646)

C++11 is required only because you're using a brace initializer, right? Clang supports variadics and rvalue references even in C++03 mode, so I'm just checking.

curdeius added inline comments.Dec 2 2020, 12:15 AM
libcxx/test/support/make_implicit.h
25 ↗(On Diff #308646)

Brace initializer, rvalue references and variadics, also std::forward but that could be just a static_cast. I can make it work for C++03 then.

curdeius updated this revision to Diff 308902.Dec 2 2020, 12:56 AM
  • Update status page.
  • Generalize tests. Clean up.
  • Remove requirement for > C++11 in make_implicit.h.
curdeius marked an inline comment as done.Dec 2 2020, 1:02 AM

I removed the unnecessary check for > C++11 in make_implicit, but that doesn't change a lot as it's used anyway only in C++20.
Anyway, I've just seen that P0935 has been adopted as a DR applied retroactively to previous standards down to C++11. My only source tho is https://en.cppreference.com/w/cpp/numeric/random/uniform_real_distribution/uniform_real_distribution.
Should I apply it to pre-C++20 then?

curdeius updated this revision to Diff 308912.Dec 2 2020, 1:52 AM
  • Fix status page.
ldionne added a subscriber: tcanens.Dec 8 2020, 8:58 AM

I removed the unnecessary check for > C++11 in make_implicit, but that doesn't change a lot as it's used anyway only in C++20.
Anyway, I've just seen that P0935 has been adopted as a DR applied retroactively to previous standards down to C++11. My only source tho is https://en.cppreference.com/w/cpp/numeric/random/uniform_real_distribution/uniform_real_distribution.
Should I apply it to pre-C++20 then?

It was adopted as a paper, and it does *not* appear to have been voted as a DR. I found on the Rapperswill (2018) wiki motion page:

Motion 25
Move to apply to the C++ working paper the proposed wording in P0935R0 (Eradicating unnecessarily explicit default constructors from the standard library).

It doesn't appear to be applied as a DR, however the author himself was the one to change cppreference (looking at the history). @tcanens Do you have more context?

tcanens added a comment.EditedDec 8 2020, 9:15 AM

I removed the unnecessary check for > C++11 in make_implicit, but that doesn't change a lot as it's used anyway only in C++20.
Anyway, I've just seen that P0935 has been adopted as a DR applied retroactively to previous standards down to C++11. My only source tho is https://en.cppreference.com/w/cpp/numeric/random/uniform_real_distribution/uniform_real_distribution.
Should I apply it to pre-C++20 then?

It was adopted as a paper, and it does *not* appear to have been voted as a DR. I found on the Rapperswill (2018) wiki motion page:

Motion 25
Move to apply to the C++ working paper the proposed wording in P0935R0 (Eradicating unnecessarily explicit default constructors from the standard library).

It doesn't appear to be applied as a DR, however the author himself was the one to change cppreference (looking at the history). @tcanens Do you have more context?

LWG doesn't do official DRs like ever, so cppreference policy for the library is that we look at what implementations do (or make an educated guess/prediction about what they will do) to call things "DRs". We are trying to document things for programmers, not standard archaeologists or language lawyers.

Both libstdc++ and MSVC implement P0935 unconditionally, so I suspect that I guessed correctly for this case.

ldionne requested changes to this revision.Dec 8 2020, 9:40 AM

LWG doesn't do official DRs like ever,

I'm not sure I follow. Aren't all LWG issues considered DRs and "back applied" to earlier standards, hence what we do in the libraries wrt LWG issues?

so cppreference policy for the library is that we look at what implementations do (or make an educated guess/prediction about what they will do) to call things "DRs". We are trying to document things for programmers, not standard archaeologists or language lawyers.

I think it's misleading to call it a DR if it isn't one. I believe it would be more correct (and equally useful) to say that most implementations support it back in C++11, without using the word DR. It's a bit pedantic, but I think nothing is lost by being more precise.

Both libstdc++ and MSVC implement P0935 unconditionally, so I suspect that I guessed correctly for this case.

@curdeius In that case, I believe we should support it unconditionally as well. At worst, it's a very very small extension in older standards. That'll also simplify the implementation and the tests a bit.

This revision now requires changes to proceed.Dec 8 2020, 9:40 AM

LWG doesn't do official DRs like ever,

I'm not sure I follow. Aren't all LWG issues considered DRs and "back applied" to earlier standards, hence what we do in the libraries wrt LWG issues?

LWG doesn't move issue resolutions as formal DRs the way CWG does. And not all issues are DRs - see, e.g., LWG2911 aka is_aggregate. I think the "file an issue if you want a paper back applied" process (as in LWG3494) is a fairly new invention.

so cppreference policy for the library is that we look at what implementations do (or make an educated guess/prediction about what they will do) to call things "DRs". We are trying to document things for programmers, not standard archaeologists or language lawyers.

I think it's misleading to call it a DR if it isn't one. I believe it would be more correct (and equally useful) to say that most implementations support it back in C++11, without using the word DR. It's a bit pedantic, but I think nothing is lost by being more precise.

I think that adds unnecessary confusion and complexity, not to mention that ISO rules say that DRs only apply to the immediately previous standard so we still have similar problems with stuff that goes back farther than that. But I don't think this is the right place to discuss cppreference policy.

I think that adds unnecessary confusion and complexity, not to mention that ISO rules say that DRs only apply to the immediately previous standard so we still have similar problems with stuff that goes back farther than that. But I don't think this is the right place to discuss cppreference policy.

Indeed, I was just giving my opinion :-). cppreference is a great tool nonetheless.

@curdeius Let's implement this back to C++11 if that's OK by you. That way, we'll remove implementation divergence and simplify our life, and we'll also make cppreference tell the truth. 😁

OK. No problem. That will be a nice cleanup indeed.

curdeius updated this revision to Diff 310784.Dec 10 2020, 12:31 AM
  • Apply to pre-C++20. That requires tho that the compiler supports delegated constructors in C++03 (it seems that clang does).
curdeius updated this revision to Diff 310826.Dec 10 2020, 3:46 AM
  • Revert for C++03 (no delegating constructors).
curdeius updated this revision to Diff 310839.Dec 10 2020, 4:35 AM
  • Fix C++03.

Friendly ping.

ldionne accepted this revision.Jan 18 2021, 12:01 PM

I didn't look again in detail, but I remember I was OK with the patch except for the question of whether to implement it as a DR. This has been settled now, so this LGTM. Thanks!

This revision is now accepted and ready to land.Jan 18 2021, 12:01 PM
curdeius updated this revision to Diff 317411.Jan 18 2021, 12:54 PM

Rebase to trigger CI to reverify.