[libcxx-dev] test/std/utilities/template.bitset/bitset.cons/string_ctor.pass.cpp

[Eric Fiselier via libcxx-dev]

They're not necessary if you allow `std::string<>` to be instantiated with
garbage.

We found it distasteful that `std::bitset` poisoned overload sets
containing it.
For example, MSVC should accept this code but instead emits a hard compile
error.

void f(std::bitset<101>);
void f(void*);
void* p;
f({p}); // Blows up.

So despite the standard not requiring `std::bitset` to SFINAE it's
constructors,
it probably means to require that they don't poison overload resolution by
blowing up.

/Eric

On Wed, Oct 9, 2019 at 10:08 AM Casey Carter via libcxx-dev <
libcxx-dev at lists.llvm.org> wrote:

> The subject test includes this function:
>
> void test_for_non_eager_instantiation() {
>
>     // Ensure we don't accidentally instantiate `std::basic_string<Nonsense>`
>     // since it may not be well formed and can cause an error in the
>     // non-immediate context.
>
>     static_assert(!std::is_constructible<std::bitset<3>, Nonsense*>::value, "");
>
>     static_assert(!std::is_constructible<std::bitset<3>, Nonsense*, size_t, Nonsense&, Nonsense&>::value, "");
> }
>
>
> which requires nonstandard behavior. Should these assertions be
> libc++-specific? (Should someone file an LWG issue to standardize the
> expected behavior?)
> _______________________________________________
> libcxx-dev mailing list
> libcxx-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/libcxx-dev/attachments/20191025/85ff7c02/attachment.html>