Re: [boost] Provisional Boost.Generic and Boost.Auto_Function (concepts without concepts)

Subject: Re: [boost] Provisional Boost.Generic and Boost.Auto_Function (concepts without concepts)
From: Dave Abrahams (dave_at_[hidden])
Date: 2010-12-15 18:48:04

At Wed, 15 Dec 2010 16:52:10 -0500,
Matt Calabrese wrote:
> 
> On Wed, Dec 15, 2010 at 4:06 PM, Matt Calabrese <rivorus_at_[hidden]> wrote:
> 
> > Marcin Zalewski answered this in a more recent reply in this thread --
> > apparently the last draft with concepts specifies that the two concept maps
> > are checked for compatibility. There is an error if there is conflict. I
> > should probably be able to do something similar in Generic, though it may
> > end up being complicated (and complicated is a relative term with respect to
> > the library already). With the implementation I'm imagining I can already
> > see an ODR issue that would be tough, but not impossible, to account for.
> >
> 
> Actually, I'm going think about this for a while. Even though Steven's
> answer wasn't accurate, at least with respect to the last draft with
> concepts, 

There was never a draft that required maps for all the parent concepts.

> I think his answer is much more feasible to implement 

Well, that's an important criterion.

> and should
> be just as capable, even though it unfortunately requires those who are
> writing concept maps to split up the implementation among the refinements.
> Given that concept map definitions are often empty anyway, I don't think
> this should be too horrible. Which direction I go can mean the difference
> between having things implemented in a couple of weeks vs months, so I'll
> probably end up using Steven's approach for now, but I'll try to leave open
> the possibility for more true-to-c++0x behavior in the future, since I think
> that would ultimately lead to the most concise code for programmers creating
> concept maps.
> 
> If anyone notices a problem with Steven's solution please bring it to my
> attention as soon as possible since I'm likely going to devote a bit of time
> to implementing it.

I think from a usability perspective it's problematic, and could
impair adoption, but I see nothing wrong with using it as a
stepping-stone.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com