Have people been thinking about how to make us compatible with https://docs.google.com/viewer?a=v&pid=forums&srcid=MTEwODAzNzI2MjM1OTc0MjE3MjkBMDIyMjg0NDY2NTc4NzYyMDQzODYBX1RlYjRCNjREQUFKATAuMQFpc29jcHAub3JnAXYy&authuser=0 ?
Ability to communicate high-level errors between the three systems languages is a high priority thing for the new static exceptions proposal.
I haven't looked at that specific proposal, but I do think that we should find ways to be "officially" compatible with various other exception mechanisms
this came up in the context of
setjmp etc as well
and Microsoft's error handling mechanism, the name of which escapes me just now
woah that stuff looks extremely familiar
are they copying this from Rust verbatim? ;)
they even have
I don't wish to mention the `m word' in this paper,
SEH, but to be clear this is _extremely_ different. This has a similar ABI to Rust Either<T, E>, and is written like those
throws functions that may or may not have gotten int
to me this sounds like having two return continuations
in CPS terminology
which they also avoid talking about, but still, that's exactly what it is?
similar, yeah, but using the return slot
it's really just
with a special ABI
So it always jumps back to the same address, and the only special thing is an enum layout optimization where the tag is stored in some flag register?
did they do this after seeing how well it works in Rust?
Rust isn't mentioned, except for the changelog saying it used to be mentioned^^
I think they mostly took it from Haskell?
but I imagine that Rust was also a major inspiration
so Haskell has sth. like
but the older papers included a "what this might look like in Rust"
because they really want ABI-compat for this between the three languages
Haskell has monads, so it doesn't need
well for us it would be a special ABI, I guess, for functions returning
but everything else would just work
yeah, that was their plan
what ever happened with
fn blah() -> T throws U
we've talked about enhancing the Rust ABI to treat
seems like it would be good to be compatible, in that case
I think @RalfJ meant SEH for Windows?
Is there a specific reason that unwinding isn't cross-language compatible? The Itanium ABI, at least, is specifically designed to allow interplay between unwinding mechanisms in a safe way.
(I need to read the paper still)
FWIW if this ends up with anyone going to a C++ committee meeting, I'd be happy to have an excuse as I would love to meet up with a number of friends. ;)
(Ah, I see that unwinding isn't directly related to this proposal because it mostly intends to avoid it, but it is necessary for
setjmp and SEH as well as existing C++ exceptions)
Wow, I dislike the proposed C++ type using
void* and suggesting putting a pointer to a dynamic allocation into a
intptr_t. I agree that we could do it with special ABI, but we'd have to be careful whether that imposes a performance hit because of having to translate between the memory and calling-convention representations.
Possibly it would make sense to have an
extern "throws" ABI as an interim measure?
The author of the paper had some progress to report yesterday:
The WG14 discussion on this just closed. I won't repeat my notes here as it is bad form to do so (official minutes only!), but I think I am allowed to say that the vote went as follows:
Does WG14 like the general direction of N2289?
Favour: 15 Opposed: 2 Abstentions: 2