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: 2023-02 meeting #3437

Closed
61 tasks done
StephanTLavavej opened this issue Feb 12, 2023 · 3 comments
Closed
61 tasks done

Meta LWG issue: 2023-02 meeting #3437

StephanTLavavej opened this issue Feb 12, 2023 · 3 comments
Labels
LWG Library Working Group issue meta Issues about issues! resolved Successfully resolved without a commit

Comments

@StephanTLavavej
Copy link
Member

StephanTLavavej commented Feb 12, 2023

(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

@StephanTLavavej StephanTLavavej added LWG Library Working Group issue meta Issues about issues! labels Feb 12, 2023
@CaseyCarter

This comment was marked as resolved.

@CaseyCarter

This comment was marked as resolved.

@frederick-vs-ja
Copy link
Contributor

  • This is "naturally enforced" (as we attempt to copy) and the error messages should be sufficiently clear.

This is currently not enforced by MSVC (DevCom-1638273). I'll open a PR for workaround.

@StephanTLavavej StephanTLavavej added the resolved Successfully resolved without a commit label Nov 12, 2023
@StephanTLavavej StephanTLavavej changed the title February 2023 LWG issues Meta LWG issue: 2023-02 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

3 participants