Hi all, Please find my review of Type Erasure below.
Please state clearly whether you think this library should be accepted as a Boost library.
Yes.
1. What is your evaluation of the design?
The library is easy to use, at least for the use cases I am interested in. Still it provides what I consider to be very very advanced features. Though, I'd question the need for some those very advanced functionalities. Will many people use something has cumbersome as : tuple<requirements, _a, _b> t(&array[0], 2); any<requirements, _a> x(get<0>(t) + get<1>(t)); I can't really evaluate if this has a huge cost in terms of complexity in the code but I think the usages (i.e. the benefits) are likely to be limited even among library developers. (By the way can this be considered multi dispatch in C++ ?) For instance, if removing this feature or simplifying the construction would allow removing the possibility to construct a "reference any" from a "reference-to-const any" I'd choose to remove the bug. Now, I may be not knowledgeable enough to judge this point precisely. I think I may limit the use cases of Type Erasure to "super interface" and that there is more to it.
2. What is your evaluation of the implementation?
The implementation is nearly not documented. There are very few comments in the private part of the code and there is no coding guidelines. This makes a review of the implementation very hard especially because a library like this is composed mostly of boilerplate TMP code. I wanted to figure out how the vtable was created and used, but I got discouraged. Adding some help for would be hackers could be interesting. Overall, the library has been submitted while still "young" (I am not disregarding the many month of efforts that were likely put into this). Steven mentions that he has not tried optimizing it yet. This is a sound choice for a young library but I'd recommend it to be done (and reviewed) before the library is released. We want to avoid a "boost::function effect" : a different guy slapping the library for being to slow and having a better design every 6 month. I think no one so far reviewed the implementation so it won't hurt to have a second round. Another thing, would be to work on error messages, because this being C++ they are horrible. I don't know if static asserts may help a lot easily or not, but if anything can be done, it'll be welcome.
3. What is your evaluation of the documentation?
This is clearly the weak point of the library. The library offers a new style of programming. One that deserves a proper step by step tutorial. One that deserves a few guidelines. Right now it's more or less backward. Very advanced concepts like placeholder types jointly capture variables are introduced before showing how to make your own concept and what's a concept by the way. There are simple usages of Type Erasure that should be made more accessible. I have been writing a sample tutorial that reflects how I would have liked to learn what Type Erasure is about. Please find it attached. It doesn't pretend to be complete or correct (it could use a serious amount of re reading) but it shows what I believe to be a much more natural progression. Please excuse me for the ugly shell in a .txt but work happened. I had no time for better. Some other pieces of advice: - I'd rename "concept map" to "concept adapter". There's no map for the user, it's your internal logic that is using one to find the correct adapter for a given concept and type. - I'd rewrite the "Concept Definitions" page. You define 3 kinds of high level concepts first, then explain what a primitive concept is. I'd keep the placeholder stuff for a different section. The good point is that the reference documentation looks complete and helpful.
4. What is your evaluation of the potential usefulness of the library?
It's huge. While writing interfaces behaving similarly was somehow always possible it was way too much of a pain to actually implement each time and few people actually dived. Type Erasure does an excellent job at streamlining the writing of interfaces. It has a good chance to become as ubiquitous as the libraries it generalizes (any and function). It may be too young to be a candidate for the next C++ standard update but it feels more than adequate.
5. Did you try to use the library? With what compiler? Did you have any problems?
I used the library to write simple tests programs only. I used g++ (4.6) and clang (3.0) in both C++03 and C++11 modes. No problems besides the fact that this is advanced C++ TMP and that the error messages are as unfriendly as usual.
6. How much effort did you put into your evaluation? A glance? A quick reading? In-depth study?
In-depth study.
7. Are you knowledgeable about the problem domain?
No I am not. I am just familiar with more traditional type erasure having implemented a couple of type erased wrappers. Many thanks to Steven for the library, it clearly offers new perspective for C++. Regards, Julien