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

Subject: Re: [boost] [GSoC] [Boost.Hana] Formal review request
From: Robert Ramey (ramey_at_[hidden])
Date: 2014-08-01 11:22:02

Roland Bock-2 wrote
> On 2014-07-31 19:54, Robert Ramey wrote:
>> Eric Niebler-4 wrote
>>> On 07/29/2014 05:14 PM, Niall Douglas wrote:
>>>> I'm all for Concepts as in compiler enforced ones, and I'll add them 
>>>> to AFIO when and only when C++ gets them. But for documentation they 
>>>> don't help.
>>> Wow, I couldn't disagree more. I can't imagine how the standard
>>> algorithms would be specified without the use of concepts like
>>> "RandomAccessIterator", for instance. Clustering requirements into
>>> meaningful abstractions and assigning them names makes it possible to
>>> document library interfaces without an explosion of verbosity and
>>> repetition.
>> +10
> +10
> 
> 
> Can't wait till Concepts Lite are there!
> 
>>
>> Usage of concepts is greatly:
>>
>> a) misunderstood
>> b) misunderestimated as to their value in design AND documentation
> 
> Right, last year, I heard several people basically asking "why on earth
> would anyone want this?" after listening to a talk about Concepts Lite.
> It took me a about an hour at dinner to convince some of them that it
> might be worth looking into the topic a bit more...
> 
>> d) The word "concepts" is a big contributor to the problem - substitute
>> "type requirements" or "type constraints" for concepts.
> 
> I like "type constraints" best.
> 
>> c) usage of concepts is much confused with implementation of concepts. 
>> Usage of "type constraints"
>> doesn't require any special support from C++.  static_assert with type
>> traits is usually all that is 
>> necessary.
>> e) recent papers using examples such as "Sortable" add more bad advice
>> and
>> confusion.
>>
>> I've included a page in the Boost Incubator to promote my views on the
>> subject - if anyone cares.
>>
>>/http://rrsd.com/blincubator.com/advice_concepts
> 
> Very nice compilation!
> 
> I am impressed by Boost Concept Check Library (the second link to it is
> broken in your document, btw). But I feel rather helpless when stumbling
> over problems (for example, your code does not compile with the
> admittedly ancient boost 1.46 on my machine and I have no idea what to
> do with the compile errors).
> 
> I am therefore rather sticking with static_assert to enforce constraints
> with friendly error messages for the time being until Concepts Lite are
> available as TS or part of the standard.

I want to actively promote the usage of "template parameter type
requirements"
in Boost Library design.  And I'm very interested in getting help on this. 
As
a start, I'd be happy to receive suggestions for amendments / enhancements
to the page on the incubator.
http://rrsd.com/blincubator.com/advice_concepts .
These suggestions / enhancements can be posted as comments to the page.
In particular, I'm interested in the following:

a) promoting the usage of the term "type parameter constraints" (or
something
similar over the very confusing term "concepts"

b) settlement of "best practice in the real world" of implementation of this
idea.
I recommended Boost Concept Check.  Which isn't bad for a start, but isn't
perfect either.  I ideally I would like to see this used where its a good
fit
and an alternative for cases where it isn't.

c) perhaps a recommendation as to whether "type constraint classes" be used
as members or base classes for checking.

d) the promotion of the idea that type reference documentation look more
like STL documentation and explicitly reference "type constraint" pages.

I'm intrigued by the mention of enable_if.  I would like to know how that
might
be used in this context.  I'm also wondering if it would applicable in
places
where I've used BOOST_STATIC_WARNING which has been useful - but unreliable.

Robert Ramey

> Cheers,
> 
> Roland
> 
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost

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