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

Subject: Re: [boost] [Concepts] Definition. Was [GSoC] [Boost.Hana] Formal review request
From: Robert Ramey (ramey_at_[hidden])
Date: 2014-08-05 11:29:41

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

I don't think we want to alter this definition.  It's not formal (in the
mathematical sense), but it's not ambiguous in our context.

My complaint isn't the definition - it's the phrase/word that was chosen to
embody the idea.  The word chosen was "Concepts" which, in my view has led
to all sorts of confusion to the casual reader - as most of are when we read
documentation.  So my view is that we would be better served by using the
term "type requirements" and/or "type constraints" rather than the word
"Concepts".  That's all.  Of course people can and will continue to use the
word "Concept" in the way they have been.  But that doesn't prohibit me from
using the phrase "type constraint" from referring to the original idea.

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

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 today we have the boost concept library which while it doesn't make
concepts part of the language itself provides a library which permits type
requirements to be specified as part of the code and checked at compile
time.

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 .  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");
};

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);

So f would be declared for a type T if and only if T were
DefaultConstructible.

Basically, this implements most of the functionality in Boost Concept
Checking and also Concepts Lite
today - and in a way which dovetails with what is (in my view) the preferred
documentation approach.
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.

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.

Robert Ramey

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