Re: [boost] [system] Would it be possible to trial a breaking change to Boost.System and see what happens?

Subject: Re: [boost] [system] Would it be possible to trial a breaking change to Boost.System and see what happens?
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2018-01-13 13:18:15

On 01/13/18 03:15, Peter Dimov via Boost wrote:
> Andrey Semashev wrote:
> 
>> > 3, Make the default constructor constexpr, now possible. No code 
>> should > notice a difference, except less runtime code will be generated.
>>
>> Not sure there will be any difference in the generated code, since the 
>> constructor still has to initialize the int and the pointer.
> 
> constexpr guarantees static initialization, and therefore that no 
> additional code needs to run except for the initialization of the int 
> and the pointer. Specifically, that system_category() does not do 
> anything else besides returning a pointer. At present, its 
> straightforward implementation initializes a function-local variable, 
> which is required to be thread-safe and therefore requires synchronization.

I don't think the standard requires this implementation. 
`system_category()` may return a pointer to a global caregory instance, 
which is initialized before `main`.

Regarding static initialization and constexpr, again, I'm not sure I see 
how useful this is. I've never needed global `error_code` instances, let 
alone statically initialized ones. I think most of my uses of 
`error_code` are either local to function scope or a member of an 
exception class or something like that. In any case, I believe the 
default constructor of `error_code` can still be constexpr if it takes a 
pointer of the global category instance directly.