cplusplus / draft

C++ standards drafts
http://www.open-std.org/jtc1/sc22/wg21/
5.65k stars 746 forks source link

Reuse `class-type`? #7175

Open hewillk opened 1 month ago

hewillk commented 1 month ago

<execution> introduces the following exposition-only concepts:

template<class From, class To>
  concept decays-to = same_as<decay_t<From>, To>;             // exposition only

 template<class T>
  concept class-type = decays-to<T, T> && is_class_v<T>;      // exposition only

which used to constrain

// [[exec.adapt]], sender adaptors
template<class-type D>
  struct sender_adaptor_closure { };

This is basically similar to the constraints we have for view_interface and range_adaptor_closure in <ranges>:

template<class D>
  requires is_class_v<D> && same_as<D, remove_cv_t<D>>
class view_interface;

template<class D>
  requires is_class_v<D> && same_as<D, remove_cv_t<D>>
class range_adaptor_closure { };

Not sure if reusing the class-type is worth the simplification (if LWG is needed):

template<class-type D>
class view_interface;

template<class-type D>
class range_adaptor_closure { };
jensmaurer commented 1 month ago

This feels editorial to me. I prefer the formulation in view_interface, however. Moving the definition of class-type to [expos.only.entity] seems in order. Can we then get rid of decays-to entirely?

@jwakely ?

hewillk commented 1 month ago

This feels editorial to me. I prefer the formulation in view_interface, however. Moving the definition of class-type to [expos.only.entity] seems in order. Can we then get rid of decays-to entirely?

@jwakely ?

decays-to seems to be a very common concept, and I believe it is used in some form or another in the standard. Perhaps we can reuse decays-to, too.