Hi Lucanus,
There are cases where reading the C++ standard will inform a developer that reinterpret_cast is safe [snip] Specifically, I submit that inheritance and composition are such cases provided that additional data members are not added in the subtype or composed type.
What *exactly* in the standard supports your claim? Please notice that I am being purposedly pedantic but not to annoy you. My intention is to make a point about why the BGL approach to adaptation (the one Joel has been explaining) is better. I think that your design is based on unspecified behavior, and, given that there are equally valid alternatives, this is unjustified. I could be wrong, so you can show us where in the std is specified that the cast is safe even in this controlled conditions?
I don't make the user reinterpret_cast for themselves, but instead provide mimic() and yield() functions for casting to and from my Concept type.
But the C++ type system doesn't support "mimicing". These functions, by name alone, speak by themselves: they are unusual hacks. (not the mentioned that yield is strongly associated with something different) You said in the presentation that you are submitting this to boost not just because of what is does but because of how it does it, to set an example. Well, given the widely known, well documented and proven adaptation pattern commonly used here in Boost, which is ignificatly different from the one you are proposing, you need to make an unusual effort and convince us that this "mimic" hack is a actually good example.
If this use of reinterpret_cast to change the behavior of an object is unacceptable for a boost submission that pretty much closes the whole case, since the design pattern depends upon it in a very necessary way. Obviously, we should sort this issue out.
What makes it unacceptable, for me at least, is that it is unnecesary. And in fact, it seems that you are aware of that since you mentioned that your first idea was to use free-functions (as the BGL and pretty much every generic library afterwards) but your users managed to convice you that "mimicing" (if I may) was better (what a shame ;)). Keep in mind that submitting a library to boost not always means that the design/code is accepted in the form it was originally created. Sometimes, if not often, acceptance requires a complete re-design and/or re-implementation. But Turst Boost, you can rest assured that such a transformation will be well worth it.
There was once an experiment on group learning conducted on monkeys. A group of monkeys in a cage had an electrified banana lowered into it periodically. They quickly learned not to touch it. When new monkeys were introduced into the cage the other monkeys went to extreme measures to prevent them from touching the electric banana. Old monkeys were removed and new monkeys added until eventually no monkey present had ever touched or seen another monkey touch the banana, but still they prevented any new monkey from breaking the taboo. At that point it became impossible for the monkeys to ever learn that the banana was safe, because even if they touched it and didn't get shocked they wouldn't know that the circumstance had changed.
Precisely... they woudn't know. In fact, they couldn't, as they don't know how to test if the bannana is still eletrified or not. Staying unconditionally away from the banana is the only reliable way for them to avoid damage. That same happens with software, relying on facts that "ought to be true" when we don't really know is risky, and risks are taken only when there is a good reason for it. In your case, I don't see any. Best Fernando Cacciola