Re: [boost] Proposed SG14 <system_error2> ready for feedback

Subject: Re: [boost] Proposed SG14 <system_error2> ready for feedback
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2018-03-03 16:57:17

>> Â Â Â Â  A more useful type erased edition is `status_code<erased<T>>`
>> 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<erased<T>>` 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/