on Fri Aug 18 2017, Joe Groff <swift-evolution@swift.org> wrote: >> On Aug 17, 2017, at 11:27 PM, John McCall via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> Essentially, you give Error a tagged-pointer representation to allow >> payload-less errors on non-generic error types to be allocated > >> globally, and then you can (1) tell people to not throw errors that >> require allocation if it's vital to avoid allocation (just like we >> would tell them today not to construct classes or indirect enum >> cases) and (2) allow a special global payload-less error to be >> substituted if error allocation fails. >> >> Of course, we could also say that systems code is required to use a >> typed-throws feature that we add down the line for their purposes. >> Or just tell them to not use payloads. Or force them to constrain >> their error types to fit within some given size. (Note that >> obsessive error taxonomies tend to end up with a bunch of indirect >> enum cases anyway, because they get recursive, so the allocation >> problem is very real whatever we do.) > > Alternatively, with some LLVM work, we could have the thrower leave > the error value on the stack when propagating an error, and make it > the catcher's responsibility to consume the error value and pop the > stack. We could make not only errors but existential returns in > general more efficient and "systems code"-worthy with a technique like > that.
That's how the best C++ unwiding mechanisms work already. I always thought it was off the table because we were wedded to the idea that throwing functions are just effectively returning a Result<T> normally under the covers, but if not, so much the better! -- -Dave _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution