<concepts>: std::default_initializable accepts types that are not default_initializable

[mordante]

Describe the bug
While implementing std::default_initializable in libc++ (https://reviews.llvm.org/D93461) I noticed some difference between libstdc++ and libc++ versus MSVC. I believe the MSVC implementation accepts types as std::default_initializable while they shouldn't be accepted. Casey Carter (@CaseyCarter) this is probably something you want to look at.

Command-line test case
The code is tested with Godbolt with MSVC v19.28 using the option /std:c++latest
https://godbolt.org/z/7dc5Kq

#include <concepts>
int main() {
    struct S0 { explicit S0() = default; };
    S0 x0;
    S0 y0{};
    static_assert( std::constructible_from<S0>);
    static_assert( std::default_initializable<S0>);

    struct S1 { S0 x; }; // Note: aggregate
    S1 x1;
    //S1 x3{}; // MSVC accepts this line, clang and gcc reject it.
    static_assert( std::constructible_from<S1>);
    // Only MSVC fails assert, probably due to accepting S1 x3{};
    static_assert(!std::default_initializable<S1>);

    const int y20{};
    // const int y21; // All compilers reject this line.
    static_assert( std::constructible_from<const int>);
    // Only MSVC fails static_assert at line below
    static_assert(!std::default_initializable<const int>);

    const int y30[1]{};
    //const int y31[1]; // All compilers reject this line.
    static_assert( std::constructible_from<const int[1]>);
    // Only MSVC fails static_assert at line below
    static_assert(!std::default_initializable<const int[1]>);

    // Zero-length array extension
    static_assert(!std::constructible_from<const int[]>);
    static_assert(!std::default_initializable<const int[]>);
}

Expected behavior

• I expect the line S1 x3{}; to be rejected by MSVC, this might be a compiler bug and not a library bug.
• I expect all static_asserts to pass.

STL version
Godbolt using MSVC v19.28

[CaseyCarter]

This test case has the expected behavior compiling with Clang, but not with MSVC, which suggests that the compiler is to blame. Indeed, our test cases for default_initializable have a great many const meow negative test cases disabled for MSVC annotated with the internal bug number VSO-1084668, which corresponds to the public bug DevCom-952724. (This test predates open-sourcing, or it would refer to the DevCom bug. I may push a change to those comments to do so now while I'm here looking at it.)

MSVC happily brace-initializing the Tim Song Aggregate is, sadly, news to me. I'll report a compiler bug and add another test case, disabled for MSVC with bug number annotation. (EDIT: this is now DevCom-1326684.)

[mordante]

Thanks for the confirmation and filing the compiler bugs.

[frederick-vs-ja]

This seems fixed in VS2022 17.14 (Godbolt link).