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

Subject: Re: [boost] [GSoC] [Boost.Hana] Formal review request
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2014-08-01 17:41:09

On 1 Aug 2014 at 9:46, Eric Niebler wrote:

> On 08/01/2014 08:22 AM, Robert Ramey wrote:
> > 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.
> 
> Boost Concept Check is horribly dated and very limited, IMO. For my work
> on a new range library[*], I built a new concept check library for
> C++11. You define a concept like:
> 
> namespace concepts
> {
>     struct BidirectionalIterator
>       : refines<ForwardIterator>
>     {
>         template<typename I>
>         auto requires_(I i) -> decltype(
>             concepts::valid_expr(
>                 concepts::model_of<Derived>(
>                     category_t<I>{},
>                     std::bidirectional_iterator_tag{}),
>                 concepts::has_type<I &>(--i),
>                 concepts::has_type<I>(i--),
>                 concepts::same_type(*i, *i--)
>             ));
>     };
> }
> 
> template<typename I>
> using BidirectionalIterator =
>     concepts::models<concepts::BidirectionalIterator>;
> 
> 
> Then you can use it like a constexpr Boolean function in enable_if,
> which can be conveniently wrapped in a simple macro like:
> 
>     template<typename I, CONCEPT_REQUIRES_(BidirectionalIterator<I>())>
>     void advance(I i, iterator_difference_t<I> n)
>     {
>         // ...
>     }

This is neat, but it still isn't really what I want.

What I want is for the tedium of writing STL iterators and containers 
to go away. I want the compiler to tell me how and why my containers 
and iterators are incomplete and/or wrong where possible without them 
being instantiated first, but if instantiated why they're incomplete 
and/or wrong with the instantiated type(s). I then want to flip that 
on its head, and have the compiler generate the STL boilerplate for 
me, so for example I ask the compiler to generate for me these 
following variants of STL containers all from the same abstract base 
meta-container:

concurrent_unordered_set
concurrent_unordered_map
concurrent_unordered_multimap

... by me specifying the absolute minimum physical typing necessary 
to delineate the differences, and then the compiler inferring the 
rest by stripping it from the system's unordered_map implementation 
for me so I don't have to.

I appreciate that such a language isn't C++, either today or 
tomorrow. But that is what I would like one day, and it surely is 
feasible given enough resources thrown at it. And besides, such 
functionality really would be very cool.
 
Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/