> On Aug 17, 2017, at 11:27 PM, John McCall via swift-evolution > <[email protected]> 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. -Joe
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
