[libcxx-dev] test/std/utilities/template.bitset/bitset.cons/string_ctor.pass.cpp
Eric Fiselier via libcxx-dev
libcxx-dev at lists.llvm.org
Fri Oct 25 15:28:54 PDT 2019
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>
More information about the libcxx-dev
mailing list