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

Subject: Re: [boost] [Concepts] Definition. Was [GSoC] [Boost.Hana] Formal review request
From: pfultz2 (pfultz2_at_[hidden])
Date: 2014-08-05 18:38:24

> Small correction: These are not constexpr functions, they are template
> structs with a value. 

Why does that matter? 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:

    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, 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();
    };

> 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.

> > 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. 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.

Regards,
Paul Fultz II

--
View this message in context: http://boost.2283326.n4.nabble.com/Concepts-Definition-Was-GSoC-Boost-Hana-Formal-review-request-tp4666011p4666099.html
Sent from the Boost - Dev mailing list archive at Nabble.com.