
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. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/