On Tue, Dec 14, 2010 at 07:41, Matt Calabrese <rivorus@gmail.com> wrote:
On Tue, Dec 14, 2010 at 7:11 AM, Matt Calabrese <rivorus@gmail.com> wrote:
Anyway, I've said more than I wanted to right now. I didn't expect this thread to be bumped -- I was hoping to post a new thread about all of this once everything was polished and up in the sandbox.
Actually, since this thread has started going again, I've hit some complicated issues regarding concept maps that I'd hope someone could help out with. In particular, there is one very troubling situation I've encountered. Imagine three concept types: a "base" concept, a "left" concept which is a refinement of "base", and a "right" concept, which is also a refinement of "base". A programmer creates a type called "foo" and wishes to make a concept map for "left" and also a concept map for "right". Because "left" is a refinement of "base", making a concept map for "left" implicitly makes a concept map for "base". Similarly, since "right" is a refinement of "base", the same thing happens. So the issue is, if someone now writes a function that requires a "base", which concept map is to be used? Should this be a compile-time error? If so, how could this possibly be safely resolved (does anyone know how this was handled in concept proposals)?
Assuming it should be a compile-time error, would it be enough to just require a third concept map to be written, explicitly for base, or perhaps a way to specify explicitly that "right" should be used? If so, what happens when a function takes a "left" and that function references the parts of the concept map that are used to satisfy the requirements of "base"? I'd imagine that it would use the "left" concept map, but that means that a different concept map for "base" would be used depending on whether the function took a "base" or a "left" or a "right", which seems to be very wrong. Am I expressing this problem correctly? Does anyone see an obvious resolution that I've missed?
Matt, I think that n2914 answers your questions (modulo any possible issues that can or have been found in the text). Here it is: http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2914.pdf This is the last draft that included concepts proposal, I believe. Specifically, 14.10.3.2 p2 says that a concept map for a refined concept is only implicitly created if it has not been found by concept map lookup. Therefore, there always be only one concept map for base. Also relevant is p5 in the same section which gives compatibility rules for "satisfiers" in concept maps for refining concepts. For example, you can have: concept A { typename T; } concept B : A {} concept C : A {} concept_map B { typedef int T; } // concept map for A implicitly created concept_map C { typedef int T; } // concept map for A found by lookup, compatibility checked There is more than that, but the basic idea is that compatibility is checked when possible, and decided negatively if it is deemed to be undecidable or too difficult to decide.
-- -Matt Calabrese _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost