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

<random>: Deprecate TR1 components in the std namespace #4284

Merged
merged 12 commits into from Jan 25, 2024

Conversation

frederick-vs-ja
Copy link
Contributor

@frederick-vs-ja frederick-vs-ja commented Dec 23, 2023

Towards #183 and #1002.

They are internally undeprecated when used as base classes. It seems that when _SILENCE_TR1_NAMESPACE_DEPRECATION_WARNING is defined, warning should still be suppressed.

TODO: need to investigate how to reuse functions from base classes. DONE

@frederick-vs-ja frederick-vs-ja requested a review from a team as a code owner December 23, 2023 15:45
@github-actions github-actions bot added this to Initial Review in Code Reviews Dec 23, 2023
@frederick-vs-ja frederick-vs-ja marked this pull request as draft December 23, 2023 16:28
@frederick-vs-ja frederick-vs-ja marked this pull request as ready for review December 23, 2023 17:22
With some workaround reusing functions from bases.
@StephanTLavavej StephanTLavavej added the enhancement Something can be improved label Jan 10, 2024
@StephanTLavavej StephanTLavavej self-assigned this Jan 10, 2024
stl/inc/random Outdated Show resolved Hide resolved
stl/inc/random Outdated Show resolved Hide resolved
@StephanTLavavej
Copy link
Member

StephanTLavavej commented Jan 19, 2024

Thanks! 😻 I pushed a conflict-free merge with main, followed by a couple of commits for feedback comments:

  • void doesn't need to return.
  • In uniform_int_distribution, drop a non-Standard operator()(_Engine&, result_type).

That non-Standard operator (originally inherited from uniform_int), combined with how the PR was defining member functions in the Standard derived classes to hide the base implementations, got me worried that there might be other members being picked up from the base classes - either entirely non-Standard, or emitting deprecation warnings.

So I pushed commits to change our inheritance to private, which will preserve the layout, and not break any guarantees that users should have been relying on, while giving us strict control over our interfaces. I then worked through the test failures and finally double-checked against the Standard that we now have all required members:

  • Private inheritance: subtract_with_carry_engine => subtract_with_carry
    • subtract_with_carry inherits from _Swc_base whose operator== is strengthened.
  • Private inheritance: mersenne_twister_engine => mersenne_twister
    • mersenne_twister operator== is strengthened.
  • Private inheritance: discard_block_engine => discard_block/_Discard_block_base
    • Note: _Discard_block_base operator== is not strengthened.
  • Private inheritance: uniform_int_distribution => uniform_int
  • Private inheritance: uniform_real_distribution => uniform_real
  • tr1/tests/random1: Check Standard names of mt19937 characteristics, add missing ones.
    • We usually don't add coverage to tr1, but I felt it was simplest to just test all of the characteristics in order.
  • VSO_0000000_instantiate_iterators_misc was calling uniform_int_distribution's non-Standard operator.

This results in nice cleanliness improvements (got rid of that non-Standard uniform_int_distribution operator(), got rid of the non-Standard characteristics in mersenne_twister_engine) and should be reasonably low risk despite the size of the changes. If anything, it makes it easier to see what the Standard classes are doing, since they now have to directly provide all members (often as wrappers).

I checked that subtract_with_carry_engine::default_seed doesn't emit deprecation warnings despite being grabbed with a using-declaration, so I think it's ok.

I definitely want a second maintainer approval here.

@StephanTLavavej StephanTLavavej removed their assignment Jan 19, 2024
@StephanTLavavej StephanTLavavej moved this from Initial Review to Final Review in Code Reviews Jan 19, 2024
Copy link
Member

@CaseyCarter CaseyCarter left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Approving in principle, but I'll probably come after these comments later if you merge them =)

stl/inc/random Outdated Show resolved Hide resolved
@CaseyCarter CaseyCarter moved this from Final Review to Ready To Merge in Code Reviews Jan 19, 2024
@StephanTLavavej
Copy link
Member

@CaseyCarter I pushed a commit to drop the pointless comments in newly added code. To avoid making this a grab-bag PR, I'm not touching pre-existing comments.

@StephanTLavavej StephanTLavavej self-assigned this Jan 24, 2024
@StephanTLavavej
Copy link
Member

I'm mirroring this to the MSVC-internal repo - please notify me if any further changes are pushed.

@StephanTLavavej StephanTLavavej merged commit c1e42b9 into microsoft:main Jan 25, 2024
35 checks passed
Code Reviews automation moved this from Ready To Merge to Done Jan 25, 2024
@StephanTLavavej
Copy link
Member

Thanks for deprecating this old machinery! 📈 🎉 😻

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Something can be improved
Projects
No open projects
Development

Successfully merging this pull request may close these issues.

None yet

3 participants