So the question is what's the upside of using the cumbersome macro rather than relying on exception handling? Is it just the perceived performance improvement?
Outcome's default configuration is to do nothing when E is a UDT. If E matches the various documented traits, observing T when an E is present will throw various exceptions according to the rules you tell it. The TRY operation is therefore an alternative way of unwinding the stack than throwing exceptions, one which does not invoke EH table scans. Sure, it's more manual and cumbersome, but it also means that the failure handling path has the same latency as the success handling path. And yes, if your EH implementation in the compiler is not table based, then there is not much performance gain. Some on WG21 have mused about an attribute by which one could mark up a function, class or namespace to say "please use balanced EH here". It would not be an ABI break, and code with the different EH mechanisms could intermix freely. If Outcome is successful in terms of low latency userbase, I don't doubt that SG14 will propose just such an EH attribute in the future. Until then, this is a library based solution. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/