Boost logo

Boost :

Subject: Re: [boost] [Concepts] Definition. Was [GSoC] [Boost.Hana] Formal review request
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2014-08-13 20:09:19

On 13 Aug 2014 at 13:42, Michael Levine wrote:

> Is there that much disagreement -- at least within the Boost community
> -- on this point ? I know that Niall expressed his viewpoint that
> compiler support is essential before developers should embrace Concepts.
> I'm not completely sure that I understand his rationale on the matter,
> and your own arguments have long ago convinced me.
> Niall: Forgive me if I am misconstruing your previous comments on the
> matter. I understood your point to be that without compiler support (in
> the form of Concepts Lite, for now), there are too many limitations with
> a Library-based system to pursue using it in code.

You're a little misconstrued :) Totally understandable given the
length of the thread.

The main essence of my objection is that Concepts Lite will make the
C++ 17 compiler a much more powerful assembler macro compiler than
the C++ 14 compiler. Concepts Lite are far "closer to the metal" in
letting you directly instruct the compiler on what macro fragments to
compose you see, so you can skip leaping through SFINAE and all the
other legacy syntax workarounds and tricks. That should very
substantially reduce memory consumption and compilation time for
compiler programming. It may even be useful to have positive effects
on metaprogramming brittleness - Andrew himself will tell you he has
no idea on the outcome here, it could go either way.

So tl;dr; I am really saying the time for concepts - whatever they
are to whoever's definition - isn't here yet. Let's get a few concept
programming libraries based on a Concepts Lite compiler around first.
Let's not dig ourselves now into a straightjacket we later regret.


ned Productions Limited Consulting

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