
A more useful type erased edition is `status_code
` which is available if `D::value_type` is trivially copyable, `T` is an integral type, and `sizeof(T) >= sizeof(D::value_type)`. This lets you use `status_code ` in all your public interfaces without restrictions. As a pointer to the original category is retained, and trivially copyable types may be legally copied by `memcpy()`, type erased status codes work exactly as normal, except that publicly it does not advertise its type. While I do see the need for providing extensions, I am not sure if status_code<void> is useful given all its "non-" characteristics. Can you elaborate on its use-cases?
`const status_code<void> &`
I propose that the customizable status_code<D> is renamed to basic_status_code<D>.
Maybe. I think customisable is the wrong adjective though. It's simply the type-aware edition, often in practice the "type restored" edition.
In keeping with the pre-established practices of std::error_code using int, I furthermore suggest that status_code becomes a non-templated alias for basic_status_code<int>.
I see active harm in doing that. status_code is type safe in a way error_code never was. So, generic_code has a value type of enum class errc for example. You cannot construct a generic_code with anything other than a errc. That's a big gain. Similarly, a com_code has a value type of HRESULT. It too cannot be constructed from anything other than a HRESULT. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/