Skip to content

Meta LWG issue: 2023-02 meeting #3437

@StephanTLavavej

Description

@StephanTLavavej

(Previous meta-issue: #3214)

At the February 2023 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-3441 Misleading note about calls to customization points
      • There's nothing to do here.
    • LWG-3827 Deprecate <stdalign.h> and <stdbool.h> macros
      • There's nothing for us to do here. These <meow.h> headers aren't part of the repo. Our <cstdalign> does define __alignas_is_defined and our <cstdbool> gets __bool_true_false_are_defined from <stdbool.h>, but the <cmeow> wrappers are already deprecated in C++17 mode (we didn't bother to implement removal in C++20 mode) and it's unclear how the UCRT could emit deprecation warnings for these macros. This isn't worth spending more time on, given that deprecation warnings aren't required for conformance (and we already go quite far here).
    • LWG-3828 Sync intmax_t and uintmax_t with C2x
    • LWG-3871 Adjust note about terminate
  • Something that increases the restrictions placed on users, but implementers aren't expected to enforce those restrictions
    • LWG-3622 Misspecified transitivity of equivalence in [unord.req.general]
      • This is N/A because it increases restrictions on users without requiring implementers to enforce them.
    • LWG-3645 resize_and_overwrite is overspecified to call its callback with lvalues
      • There's nothing for implementers to do here (it merely increases the restrictions for users).
  • Fixes for obviously broken wording, where implementers would have done the right thing anyways
    • LWG-3032 ValueSwappable requirement missing for push_heap and make_heap
    • LWG-3756 Is the std::atomic_flag class signal-safe?
    • LWG-3841 <version> should not be "all freestanding"
    • LWG-3843 std::expected<T, E>::value() & assumes E is copy constructible
      • This is "naturally enforced" (as we attempt to copy) and the error messages should be sufficiently clear.

😸 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-3811 views::as_const on ref_view<T> should return ref_view<const T>
    • LWG-3825 Missing compile-time argument id check in basic_format_parse_context::next_arg_id
    • LWG-3842 Unclear wording for precision in chrono-format-spec
      • Implemented:

        STL/stl/inc/chrono

        Lines 5301 to 5313 in 9ae1b3f

        if constexpr (_Is_specialization_v<_Ty, duration>) {
        if constexpr (!treat_as_floating_point_v<typename _Ty::rep>) {
        if (_Specs._Precision != -1) {
        _THROW(format_error("Precision specification invalid for chrono::duration type with "
        "integral representation type, see N4885 [time.format]/1."));
        }
        }
        } else {
        if (_Specs._Precision != -1) {
        _THROW(format_error("Precision specification invalid for non-chrono::duration type, "
        "see N4885 [time.format]/1."));
        }
        }
      • We go beyond the Standard by using treat_as_floating_point_v. I think this is a remaining (small) defect in the Standardese.
      • When a new Working Paper is available, we could update the Standardese citation, but this is not absolutely necessary (as the stable name and paragraph number are unchanged, and the content of the paragraph hasn't changed that much).
    • LWG-3866 Bad Mandates for expected::transform_error overloads

🩹 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

Metadata

Metadata

Assignees

No one assigned

    Labels

    LWGLibrary Working Group issuemetaIssues about issues!resolvedSuccessfully resolved without a commit

    Type

    No type

    Projects

    Status

    Done

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions