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-05 17:37:10

On 2014-08-05 17:29, Robert Ramey wrote:
> I believe that "C++ Concept" was originally defined by the following web page
> or writing contemporary to it.
> https://www.sgi.com/tech/stl/stl_introduction.html . A relevent quote is
>
> "One very important question to ask about any template function, not just
> about STL algorithms, is what the set of types is that may correctly be
> substituted for the formal template parameters. Clearly, for example, int*
> or double* may be substituted for find's formal template parameter
> InputIterator. "

"we call such a set of type requirements a /concept/. [...] We say that a type /conforms to a concept/, or that it /is a model of a concept/, if it satisfies all of those requirements".

> It's somewhat off topic, but I'm going to take the opportunity to point out 
> https://www.sgi.com/tech/stl/doc_introduction.html .  I've come to believe
> that C++ libraries - in particular parameterized types, are best described
> by the documentation approach embodied in this link.  It is sufficiently
> formal where it has to be - but not so formal that one gets too bogged down. 
> I've made a big point of this
> inhttp://rrsd.com/blincubator.com/requirements_documentation/ .   My
> criticism of the HANA documentation is really that it fails to follow this
> format and content. 
I haven't read enough documentation on Hana to comment on that, but I
agree in principle that uniformity, consistency, use of concepts etc are
extremely useful to enhance documentation. I have my doubts though, that
the STL documentation structure can be used as-is in a reasonable way
for every library.

For instance I would not know how to do that for sqlpp11, but I would
love to discuss it over a beer at CppCon.

>  One of the objections raised to my criticism is that
> this form of documentation is in some sense not modern, specific to STL, or
> in some way not a good model for all C++ libraries.  It is this idea which I
> reject - totally.  Library authors would be best served by producing this
> form of documentation (concurrently with code) and not spend any time
> re-inventing their own documentation form.  Use this one and spend your time
> on coding!
As of now, I'd say that the STL documentation provides a good starting
point for the documentation structure of most libraries (maybe all, I
don't know). But adaptations might be required to make it fit to
specific libraries.

>
> Another interesting quote is:
>
> "Concepts are not a part of the C++ language; there is no way to declare a
> concept in a program, or to declare that a particular type is a model of a
> concept. "
>
[...]
>
> But with C++11 it's much more interesting.  I just came upon:
>
> http://en.cppreference.com/w/cpp/concept
>
> which echoes my views on the whole subject.  I don't have the C++11 spec -
> but I'm assuming/hoping that these type requirements are part of it.  This
> section only defines the named type requirements.
>
> But wait!!!! there's more !!!
>
> For A good number of the concepts - example DefaultConstructable
> http://en.cppreference.com/w/cpp/concept/DefaultConstructible
>  -there exists a constexpr function such as 
> http://en.cppreference.com/w/cpp/types/is_default_constructible . 

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

> So in
> this case we DO have concepts built into the language (libraries).  Making a
> concept checking class would be as simple is:
>
> template<class T>
> struct DefaultConstructible {
>     static_assert(std::is_default_constructible<T>::value, "Class is not
> default constructible");
> };
Personally, I would say that is_default_constructible already is the
concept checking template. What you do with it is another question. You
can use in combination with static_assert if you want to emit a hard
error or you could use it with enable if, if you want to suppress
non-matching instances.

>
> Making a new concept class is pretty simple - leave as an excursive for the
> reader
>
> But wait - there's even more!!!!
>
> if there were a type trait defined for each concept - we would have type
> dispatching based on named type requirements - example
>
> std::enable_if<std::is_default_constructible&lt;T>>
> void f(const T &t);
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<T>::value,
void>::type f();
};

Now, the cool thing about the (hopefully) soon to be arriving Concept
Lite is, that even that will work

template<typename T>
struct X
{
  void f() requires std::is_default_constructible<T>::value;
};

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

>
> This is the direction we (Boost and all of C++) need to go.  That is, we've
> known what to do for some time
> we just have to start doing more.
>
>

Cheers,

Roland