Re: [boost] [Boost-users] [review][LEAF] Review of LEAF

On 01/06/2020 14:48, degski wrote:

On Mon, 1 Jun 2020 at 08:30, Niall Douglas via Boost-users mailto:boost-users@lists.boost.org> wrote:

The current formulation of lightweight exceptions before WG21 is literally Experimental Outcome in language form. Same proposed error object, std::error. It is currently expected that both value-based and type-based exceptions would exist in future C++, in order to retain backwards compatibility, as the semantics between the two are not currently believed possible to be made exactly one-one.

i am obviously oblivious to what 'is in front of', but knowing that now [what light weight exceptions entails], I concur with you. As I noted in that same post, I 'get' [in respect of LEAF] the use-case of a c-api error-handler (but there must be plenty of those, no?), but otherwise I don't see it. From my personal perspective, I would not hesitate one second to use Outcome now, instead of any other solution better, or worse, just because it is going to be in some shape or form, but very similar, in the future standard.

Just so nobody misinterprets anything, right now EWG is not keen on proposed lightweight exceptions. Microsoft hopes to modify MSVC to support an implementation in the near future, and that may change EWG's opinion. LEWG is keen, so far, on the library side of things i.e. std::error and the wider status_code machinery. We recently ported a large codebase at work from to status_code. It took about a day, and the status_code edition is considerably more flexible and useful (mainly thanks to that custom payload feature, and strongly typed code objects). The ability to quickly wrap custom enums into custom status code domains is a nice timesaver too. I should stress though that status_code natively recognises std::error_code, it automatically wraps any custom std::error_category into a synthesised custom status_code_code, so you can totally mix the two in the same codebase, and it'll all "just work". Current committee direction is that C++ 23 should get std::error and a implementation of Outcome's result<T> as std::result<T>, with E hardwired to any type deriving from std::error. This isn't as good as lightweight exceptions, but if EWG changes its mind, the library side of things is ready to go. And obviously everything I just said could change next meeting. Niall