on Fri Aug 25 2017, John McCall <rjmccall-AT-apple.com> wrote:
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. :)
The correct term, John, is “fightin'”
-Crustee
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
--
-Dave
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution