Re: [boost] [outcome] Second high level summary of review feedback accepted so far

But does this preserve the guarantee that result is trivially copyable?

Also, if you want the TRY operation to work (and you really, really do, it is an enormous boilerplate saver), then your error type needs to be identical throughout your program. Templating it breaks that.

Another alternative to consider is to change something in the ring buffer records, so that it resembles:

``` struct RingBufferRecord { enum {/*name different kind of payloads*/} _discriminator; union { /*define different kinds of payload*/ } }; ```

This way the enumeration tells you how to reinterpret the data. You do not know all possible payloads when designing the ring buffer, so you probably need to introduce something akin to virtual functions:

``` struct RingBufferRecord { aligned_storage<256> _raw_storage; void (*_interpret_raw_storage) (aligned_storage<256>&); }; ```

I admit this idea is not well thought over.

You can probably set a custom ring buffer design per process, but as it would cause error_code_extended's type signature to change in order to prevent ABI collision, going finer grained than that probably wouldn't be practical as again you'd lose the TRY operation. I am currently minded to have error_code_extended no longer store a 191 byte string which lets me pack many more of them into a reasonably sized ringbuffer. If people want to store a string, I am minded they should be either supplying a static const char * or else return an outcome<T> with shared_ptr payload to strings. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/