> On Aug 25, 2017, at 12:18 PM, Dave Abrahams via swift-evolution > <swift-evolution@swift.org> wrote: > 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.
Them's fighting words. :) John. > 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 _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
