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

The correct approach here, I think, is not to define fat error codes, but to return an outcome whose error() is the error_code and whose exception() is the appropriate filesystem_error exception, complete with the path(s).

Setting however both the error_code and the exception_ptr is not supported by the current outcome design (and neither would it be supported by expected.)

Or, an alternative that scales better would be to take

http://pdimov.com/cpp2/P0640R0.pdf

and store error_code and exception_info, so that later one can use

throw_with_info( std::system_error( error() ), info );

with the additional information (such as paths) being carried by the exception_info.

In AFIO v2 I'd personally consider any potential memory allocation in any of the core API unacceptable (because we never allocate memory in AFIO v2). Currently we memcpy() the tail of the path into the error_code_extended on failure, but even that I dislike because each afio::io_handle already knows its own path, and if it weren't for lifetime issues I'd just return the pointer to that path and save a lot of work for everybody. Down the line AFIO v2 will gain a "fat path" type which is the combination of an open handle with a path fragment. Those necessarily will need to decide what to do about lifetime issues. I may yet go light and make the fat path type just a naked pointer plus filesystem::path, or I may implement a process-wide registry of "path handles" i.e. handles opened solely to indicate some unknown location on the filesystem which is a base for path fragments to work from. I haven't decided yet, there are a lot of competing tradeoffs, I specifically want the end user to do all their malloc-work in a pre-init step and away from any core i/o loops which need to never, ever allocate memory. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/