
Hi, Now that we will have operator traits with the reviewed library and member traits macros with Boost.TTI, it left just to define the traits for the concepts/requirements of standard library and why not some boost libraries. This would completely resurrect the abandoned ConceptTraits library. Could be this an acceptable subject for GSOC? Thanks, Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/GSOC-concept-traits-tp3388859p3388859.htm... Sent from the Boost - Dev mailing list archive at Nabble.com.

Now that we will have operator traits with the reviewed library and member traits macros with Boost.TTI, it left just to define the traits for the concepts/requirements of standard library and why not some boost libraries. This would completely resurrect the abandoned ConceptTraits library.
I think it's probably a worthwhile project. It would be interesting to see what kind of proposals we'd get for a project like this. I'm not entirely sure what the scope or difficulty of this project would be. Applying these concept checks within a library is also not without (potentially high) risk. If the concept checks aren't right, you could end up breaking code. Andrew

Andrew Sutton-3 wrote:
Now that we will have operator traits with the reviewed library and member traits macros with Boost.TTI, it left just to define the traits for the concepts/requirements of standard library and why not some boost libraries. This would completely resurrect the abandoned ConceptTraits library.
I think it's probably a worthwhile project. It would be interesting to see what kind of proposals we'd get for a project like this. I'm not entirely sure what the scope or difficulty of this project would be.
My experience is that simple things are not always as simple as we thought. * Making it portable adds always a lot of issues. * Finding the correct names and interface is not an easy task as the TypeTraits operators review probes. Should I add a summary to the list of ideas? Applying these concept checks within a library is also not without (potentially high) risk. If the concept checks aren't right, you could end up breaking code. Yes, you are right. The ConceptTraits should provide just the traits for the requirements. Up to the library author to use them later. Best, Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/GSOC-concept-traits-tp3388859p3389287.htm... Sent from the Boost - Dev mailing list archive at Nabble.com.

My experience is that simple things are not always as simple as we thought. * Making it portable adds always a lot of issues. * Finding the correct names and interface is not an easy task as the TypeTraits operators review probes.
Should I add a summary to the list of ideas?
Sure. I think that this is a good idea. I might also point at my side project Origin (http://code.google.com/p/origin/), which has a similar goal. I'm basically incorporating concept checking classes and traits classes into a uniform system with the intent of actually using them in other libraries :) Of course this work is still in progress; I'm actually working on them in a slightly different context. But the idea is the same. Andrew
participants (2)
-
Andrew Sutton
-
Vicente Botet