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

Meta LWG issue: 2022-11 meeting #3214

Closed
58 tasks done
StephanTLavavej opened this issue Nov 14, 2022 · 10 comments
Closed
58 tasks done

Meta LWG issue: 2022-11 meeting #3214

StephanTLavavej opened this issue Nov 14, 2022 · 10 comments
Labels
LWG Library Working Group issue meta Issues about issues! resolved Successfully resolved without a commit

Comments

@StephanTLavavej
Copy link
Member

StephanTLavavej commented Nov 14, 2022

(Previous meta-issue: #2872)

At the November 2022 meeting, the following LWG issues were resolved in the C++ Working Paper.

❔ Not yet analyzed

  • Remaining issues:

❌ Not applicable

If an issue requires no action from implementers, we mark it as N/A. Categories:

  • Pure wording clarifications with nothing to implement (these can be changes to non-normative text like examples and informative notes, or wording cleanups to normative text that don't impact observable behavior)
    • LWG-3600 Making istream_iterator copy constructor trivial is an ABI break
    • LWG-3753 Clarify entity vs. freestanding entity
    • LWG-3781 The exposition-only alias templates cont-key-type and cont-mapped-type should be removed
    • LWG-3818 Exposition-only concepts are not described in library intro
    • LWG-3822 Avoiding normalization in filesystem::weakly_canonical
    • LWG-3824 Number of bind placeholders is underspecified
  • Something that increases the restrictions placed on users, but implementers aren't expected to enforce those restrictions
  • Fixes for obviously broken wording, where implementers would have done the right thing anyways
    • LWG-3028 Container requirements tables should distinguish const and non-const variables
    • LWG-3177 Limit permission to specialize variable templates to program-defined types
    • LWG-3597 Unsigned integer types don't model advanceable
    • LWG-3732 prepend_range and append_range can't be amortized constant time
    • LWG-3738 Missing preconditions for take_view constructor
    • LWG-3775 Broken dependencies in the Cpp17Allocator requirements
    • LWG-3817 Missing preconditions on forward_list modifiers

😸 Already implemented

Sometimes we cite LWG issues in product code comments as we're implementing their proposed resolutions. When the resolutions are officially accepted, we should remove the citations (as the default assumption is that we're implementing what the Standard says). If something is especially subtle, we can convert the citation to mention the relevant Standard section. Sometimes we should add test coverage - e.g. when the Standard begins requiring something that we were already doing, but weren't explicitly testing for.

  • Already implemented, comments need to be removed and messages need to cite the Standard
  • Implemented without comments
    • LWG-3118 fpos equality comparison unspecified
    • LWG-3636 formatter<T>::format should be const-qualified
    • LWG-3747 ranges::uninitialized_copy_n, ranges::uninitialized_move_n, and ranges::destroy_n should use std::move
    • LWG-3754 Class template expected synopsis contains declarations that do not match the detailed description
    • LWG-3755 tuple-for-each can call user-defined operator,
    • LWG-3757 What's the effect of std::forward_like<void>(x)?
    • LWG-3759 ranges::rotate_copy should use std::move
    • LWG-3765 const_sentinel should be constrained
    • LWG-3770 const_sentinel_t is missing
    • LWG-3782 Should <math.h> declare ::lerp?
    • LWG-3784 std.compat should not provide ::byte and its friends
    • LWG-3792 __cpp_lib_constexpr_algorithms should also be defined in <utility>
    • LWG-3795 Self-move-assignment of std::future and std::shared_future have unimplementable postconditions
    • LWG-3796 movable-box as member should use default-initialization instead of copy-initialization

🩹 Patches an unimplemented feature

We should record this LWG issue in the GitHub issue tracking the feature. That way, we'll remember to verify it, but it doesn't represent net new work.

🐞 Not yet implemented

@StephanTLavavej StephanTLavavej added LWG Library Working Group issue meta Issues about issues! labels Nov 14, 2022
@fsb4000

This comment was marked as resolved.

@cpplearner

This comment was marked as resolved.

@JMazurkiewicz

This comment was marked as resolved.

@frederick-vs-ja

This comment was marked as resolved.

@cpplearner

This comment was marked as resolved.

@StephanTLavavej

This comment was marked as outdated.

@strega-nil-ms

This comment was marked as resolved.

@strega-nil-ms

This comment was marked as resolved.

@CaseyCarter

This comment was marked as resolved.

@CaseyCarter
Copy link
Member

#3238 removes "LWG-XXXX" and strengthened comments for issues we already implement. With that, we're all done with classification. Thanks everyone!

@StephanTLavavej StephanTLavavej added the resolved Successfully resolved without a commit label Nov 12, 2023
@StephanTLavavej StephanTLavavej removed their assignment Mar 28, 2024
@StephanTLavavej StephanTLavavej changed the title November 2022 LWG issues Meta LWG issue: 2022-11 meeting Mar 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
LWG Library Working Group issue meta Issues about issues! resolved Successfully resolved without a commit
Projects
Status: Done
Development

No branches or pull requests

7 participants