Current status: idly musing if ‘?’ could be productively lowered to LLVM exceptions in #rustlang
@RAOF Panic (nee "fail") already is. And (amusingly) we also went through iterations on lowering panic to things more-like how ? is currently lowered, before it existed (propagated invisible return codes).
The one golden of rust language dev is "you are trapped in a time loop, everything has been tried, everything will be tried again".
@graydon
Huh!
My rationale for trying to lower the Err() half of Result<_, Err> to exceptions is optimisation - remove the branches from the success path, increase code locality by having the failure path marked and elsewhere.
What was the rationale behind lowering panics to return-and-branch?
@RAOF I don't remember exactly but IIRC it had to do with the quantity of code emitted in landing pad cleanups, possibly we were experimenting with the idea that LLVM would coalesce them better inside normal code (keep in mind: "zero cost" EH has nonzero codegen costs, it's just hypothetically "cheaper at runtime")
Or else we were still trying to decide how to deal with encoding panic for FFI (currently .. I think somewhat punted on?)
@RAOF There are several different not-compatible EH regimes on different platforms, some DW2-like and some SEH-like. Plus there are callers that are just totally EH-unaware (most C host programs) so it's a nice idea to model panics for them _somehow_.
But even FFI-aside, the perf and codegen bits are sufficiently subtle that (eg.) Swift made its own LLVM calling convention (with pinned error register) for error-returns.
@graydon Ooooh, yeah. Return-and-branch is *definitely* more friendly for FFI.
At the moment anything you want to call into via FFI needs to be built with panics-as-abort() in order to avoid nasal daemons.
I promise you won't talk me out of experimenting 😁, although any experimentation I do will be painfully slow!
@graydon Also, thanks for replying to my idle musings!