Hi, As I mentioned yesterday, I happened to stay up for a few hours and create two related proposals, after being inspired by Beman's 'identifier' suggestion (as part of his quite useful 'system-0.2' proposal.) I saw - as some people here, including Beman - a potentially wider scope for such embeddings that quite integer-centric "database key" types. The question was whether it was worth the effort. First, one needs a flexible policy system to define what structures to preserve from the underlying type. Such policies need to be injected into the ancestry tree of the embedding type. Thus, we need a hierarchy generator. We have all looked at Andrei's Loki library and its hierarchy generator - I assume. For my purposes, it was actually a bit too specific and data-holding-centric. And, I wanted it to jive with Boost.MPL. [PROPOSAL #1 - generate_hierarchy] So, I created "generate_hierarchy.hpp", which is my proposal for a hierarchy generator. It has two modes of generation: spine-like or chain, as explained in my blog (no, I am *not* promoting my crappy blog, but prefer not to repeat that discussion here...): http://davber.blogspot.com/2006/07/hierarchy-generation-in-c.html. [PROPOSAL #2 - embed_type] After having that hierarchy generator, I then took the rest of the night to create a type embedder, "embed_type.hpp". There is still some work to handle small and big types differently (reference vs. copying) and the naming of policies and such is a bit weird. In short, one can achieve an isomorphic (w.r.t. order, equivalence, arithmetics and conversion) embedding by struct MyInt : embed_type<int, MyInt> { MyInt(int num) : embed_type<int, MyInt>(num) {}; }; int foo = MyInt(42); // will compile! and if you do not want conversion to int, you can do struct MyInt : embed_type<int, MyInt, mpl::remove<embed_policy_all, policy<embed_conversion> > > { MyInt(int num) : embed_type<int, MyInt, ... [ugh, I do not like GCC 3.3 sometimes]>(num) {}; }; int foo = MyInt(42); // will not compile :-( (or should it be :-) since it was expected?) DISCLAIMER: these are quite early drafts of proposals created during one sleepness night, so spare with me. I basically want to know if there is any interest in these libraries and, if so, if they should be proposed as additions to existing Boost libraries or part of new library/ies. The two proposals (two files) with small samples (two files) are attached as a ZIP file (till I gain access to the file vault of Boost.) I will go to bed now, /David