[Bug c++/107600] New: New __is_destructible built-in

[Bug c++/107600] New: New __is_destructible built-in

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107600

            Bug ID: 107600
           Summary: New __is_destructible built-in
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

Like __is_construcible, __is_convertible, __is_assignable, it would be nice to
have an __is_destructible built-in so we don't need to instantiate all this for
every one of the C++20 concepts that depends on it:


  // In N3290 is_destructible does not say anything about function
  // types and abstract types, see LWG 2049. This implementation
  // describes function types as non-destructible and all complete
  // object types as destructible, iff the explicit destructor
  // call expression is wellformed.
  struct __do_is_destructible_impl
  {
    template<typename _Tp, typename = decltype(declval<_Tp&>().~_Tp())>
      static true_type __test(int);

    template<typename>
      static false_type __test(...);
  };

  template<typename _Tp>
    struct __is_destructible_impl
    : public __do_is_destructible_impl
    {
      typedef decltype(__test<_Tp>(0)) type;
    };

  template<typename _Tp,
           bool = __or_<is_void<_Tp>,
                        __is_array_unknown_bounds<_Tp>,
                        is_function<_Tp>>::value,
           bool = __or_<is_reference<_Tp>, is_scalar<_Tp>>::value>
    struct __is_destructible_safe;

  template<typename _Tp>
    struct __is_destructible_safe<_Tp, false, false>
    : public __is_destructible_impl<typename
               remove_all_extents<_Tp>::type>::type
    { };

  template<typename _Tp>
    struct __is_destructible_safe<_Tp, true, false>
    : public false_type { };

  template<typename _Tp>
    struct __is_destructible_safe<_Tp, false, true>
    : public true_type { };
  /// @endcond

  /// is_destructible
  template<typename _Tp>
    struct is_destructible
    : public __is_destructible_safe<_Tp>::type
    {
      static_assert(std::__is_complete_or_unbounded(__type_identity<_Tp>{}),
        "template argument must be a complete class or an unbounded array");
    };

[Bug c++/107600] New __is_destructible built-in

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107600

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
And as with the others, __is_nothrow_destructible, which is what the concepts
depend on specifically:

  /// [concept.destructible], concept destructible
  template<typename _Tp>
    concept destructible = is_nothrow_destructible_v<_Tp>;

  /// [concept.constructible], concept constructible_from
  template<typename _Tp, typename... _Args>
    concept constructible_from
      = destructible<_Tp> && is_constructible_v<_Tp, _Args...>;

And so that gets used by every one of std::default_initializable,
std::move_constructible, std::copy_constructible, std::movable, std::copyable,
std::semiregular etc.

[Bug c++/107600] New __is_destructible built-in

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107600

Marek Polacek <mpolacek at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
                 CC|                            |mpolacek at gcc dot gnu.org
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2022-11-10

[Bug c++/107600] New __is_destructible built-in

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107600

--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
I committed r13-3870-g0cbb756fe9c8e1 to speed up the std::destructible concept,
so an intrinsic is not urgent. But it would probably be even better than the
new implementation, and would also help other parts of the lib that use the
trait rather than the concept, such as std::optional and std::variant.