On Sun, Oct 14, 2012 at 4:40 AM, Lorenzo Caminiti <lorcaminiti@gmail.com>wrote:
It will have to be something like that, maybe with typename to distinguish from value template parameters as I mentioned before:
I have a little bit of magic that should allow me to handle this, relying on template magic. I can detect whether a concept name corresponds to a unary template with a type parameter as opposed to a non-type template parameter via an overloading of certain function templates that occurs when you create the initial concept. This isn't in yet, but proof-of-concepts seem to work. The only complication with this is that since the check occurs at compile-time (but not during preprocessing), the generated code needs to be... complicated. It should in theory get rid of requiring the user to make that specification, though. Anyway, since probably 99% of the time the user is working with concepts that have type parameters, I think we should aim to support that in a concise manner. I.E. instead of requiring the user to write "typename" for those concepts with type parameters, support it without typename and instead require some alternative syntax for concepts with non-type parameters, pending I can't get it all to work behind-the-scenes with the same preprocessor syntax.
Or, as I was saying, can't we just require the use of requires ;) instead:
template( typename T, typename U ) requires( ObjectType<T>, (MapType<U, T>) ) // (2)
Yeah, and that should be the main focus since it's easier to implement.
Does Boost.Generic need ObjectType and MapType separately (as per 1) or it can use their instantiations Object<T> and MapType<U, T> (as per 2)?
In most contexts you can use their instantiations directly, and you should be able to do so there. One place that may need to change is when dealing with refinement (due to the changes I'm currently making, but I may be able to come up with a hack). For example, in this concept: http://generic.nfshost.com/generic/standard_concepts/concepts/arithmeticlike... I refer to less-refined concepts I.E. HasNegate<T>, but in order to make explicit concept map templates for more-refined concepts work for less-refined concepts in a truly N2914-compliant way, I may need to change the syntax when doing refinement to something like (HasNegate)(T). -- -Matt Calabrese