Re: [boost] [Concepts] Definition. Was [GSoC] [Boost.Hana] Formal review request

Subject: Re: [boost] [Concepts] Definition. Was [GSoC] [Boost.Hana] Formal review request
From: Roland Bock (rbock_at_[hidden])
Date: 2014-08-06 02:19:35

On 2014-08-06 00:38, pfultz2 wrote:
>> Small correction: These are not constexpr functions, they are template
>> structs with a value. 
> Why does that matter? 
Just the interface. Otherwise, no.
> An integral constant type trait is the common way to
> define a concept predicate in C++, and it has many advantages over constexpr
> functions(which are quite limited).
>
>> This works, if f is a template itself, but not if it is a function
>> inside a template like this:
>>
>> template<typename T>
>> struct X
>> {
>>   typename std::enable_if<std::is_default_constructible&lt;T>::value,
>> void>::type f();
>> }; 
> Well, actually you can if you use a default template parameter:
Of course, f is then a template itself, as I said :-)

But thanks for the hint. I was not aware of this default bool trick and
am thinking about using it right now...

>
>     template<typename T>
>     struct X
>     {
>         template<bool X=true, std::enable_if_t<X && ( 
>             std::is_default_constructible<T>()
>         ), int> = 0> 
>         void f();
>     }; 
>
> Although I do find the boilerplate for `enable_if` ugly(even with the type
> alias) and error-prone
Me too, but I leave them unhidden and will feel great happiness when
cleaning up the mess with Concepts Lite (or so I hope).

> , so thats why I always use these set of macros like
> these:
>
>     #define CLASS_REQUIRES(...) typename std::enable_if<(__VA_ARGS__)>::type
>     #define REQUIRES(...) typename std::enable_if<(__VA_ARGS__), int>::type
> = 0
>     #define MEMBER_REQUIRES(...) template<bool HiddenMemberBool=true,
> REQUIRES(HiddenMemberBool && (__VA_ARGS__))>
>
> So you could write it like this:
>
>     template<typename T>
>     struct X
>     {
>         MEMBER_REQUIRES(std::is_default_constructible<T>())
>         void f();
>     };
That looks quite nice indeed.
>
>> Now, the cool thing about the (hopefully) soon to be arriving Concept
>> Lite is, that even that will work 
> Most of functionality of Concepts Lite can already can be done in C++,
> currently. It adds some syntatic sugar(which is not bad), and it trades in
> specialization for clever overloading.
Strong spices, I'd say, very tasty and much healthier than all that
sugar ;-)

Personally, I expect a similar impact as with auto.

>
>>> It makes for a coherent and complete system from coding to
>> documentation.
>>> Since most of this is "form filling" it's easy, mechanical and almost
>>> guaranteed to be correct.
>> It certainly is a good foundation. It might get a bit more complex if
>> you have variadic templates and/or constraints for the current set of
>> parameters. For instance, "no type must occur more than once in the
>> parameter list" 
> Well, checking "no type must occur more than once in the parameter list"
> should be very possible to check.
Sure, that's possible and I do it with a simple type set. My point was
that it might not be as mechanical as one would guess at first glance.
Most type requirements deal with individual types, some deal with
multiple types.

>  Actually, one of the big limitations of
> the
> current way to check type requirements(that includes both Boost.ConceptCheck
> and Concepts Lite) is that you can't check for template members or for
> template functions. It is possible to check for a function or member
> function
> that is callable with a certain parameters, but it is not possible to check
> in
> general(like how you can check for a template class).
>
> However, language limitations of checking for certain type requirements
> should not limit the documentation of those requirements. Although, it may
> be
> wise to avoid building requirements around those limitations.
+1

Best,

Roland