Re: c++0x concepts in gcc call

["Doug Gregor" <doug dot gregor at gmail dot com>]

On Jan 21, 2008 8:08 PM, Benjamin Kosnik <bkoz@redhat.com> wrote:
> Jason Merrill, Doug Gregor, and I invite all interested GCC hackers to
> discuss implementation of the compiler and library parts of the
> C++0x concepts proposals. This is to be a brainstorming session, where
> we discuss the best way to complete the work, what can be taken from
> existing branches, and how to smoothly transition between a
> concept-enabled standard library and the current libstdc++.

Some notes from the discussion in this call:

Organization:
 - We'll start a fresh branch in the FSF repository dedicated to concepts
   (it's branches/cxx0x-concepts-branch). Initially, Doug and Jason
   will be maintainers of this branch
 - We want to minimize the distance between this branch and mainline:
   * All non-concepts C++0x features will still go into mainline
   (unless they depend on concepts)
   * Type-checking of constrained templates depends on improved
   type-checking of C++98 templates (particularly, checking of
   non-dependent expressions), so we'll try to do all of this work in
   mainline
   * Doug will merge from mainline to branch regularly
 - Will salvage what we can from ConceptGCC: concept-checking,
   archetype generation, and parsing bits will be useful; type-checking
   of constrained templates needs to be reworked significantly.
 - We're not going to commit to any schedule, but it'll be a multi-year effort
 - We're going to delay any decisions about library issues for
   now. They won't matter until the front end supports enough of concepts
   to permit their use in the library

C++ front end:
 - Concepts representation:
    * Concepts, concept maps will be RECORD_TYPEs to reuse as much of
      that logic as is possible
    * Archetypes will probably need their own, new tree nodes
 - Same-type constraints and mapping to archetypes caused a lot of
   trouble in ConceptGCC: canonical types could simplify this
 - Constrained templates will create many new nodes in the internal
   representation that don't need to be around after a constrained
   template is type-checked; we might need to consider a stricter memory
   management scheme
 - Performance of the generated code was a problem with ConceptGCC,
   which Doug blames on the inliner. We should consider a limited form of
   inlining in the instantiation of constrained templates to avoid
   swamping the inliner with the forwarding functions in constrained
   templates.

For more information about the concepts branch, see
http://gcc.gnu.org/projects/cxx0x.html#concepts

For more information about ConceptGCC, see
http://www.generic-programming.org/software/ConceptGCC/

  - Doug