Boost logo

Boost :

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


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

ned Productions Limited Consulting

Boost list run by bdawes at, gregod at, cpdaniel at, john at