This is already a real and serious issue for current errors, so I’m not sure what the point is here. E.g., the panopticon error enum is currently 72 bytes; if some upstream crate adds an error with an array or a huge struct like you suggest and it gets added to the foreign links, it will extend the size…
I assume just do what error-chain or any other type that needs to be recursive does, use a Box or pointer, but perhaps your point might be more subtle here, not sure.
The array idea is interesting, but as you suggest, there are definitely some problems.
Finally, I agree
Box<Error> solves some problems, but it introduces others; and as you mention, can’t currently pattern match.
I just don’t agree; I thought I presented several reasons for why this is the case, and I don’t think it’s a matter of beginners not learning their options efficiently, as I tried to explain, 1-3 still all apply to beginners and non-beginners alike…
This is very interesting. So when you mentioned dynamic linking previously, I started thinking about how one might implement an open type like this for dynamic libraries and the problem becomes tractable when you are given a unique ID for each library that uses/extends an open type.
In linux dynamic linking this is actually the
DTPMOD64 relocation in x86_64 (which is incidentally used by
So theoretically, what’s interesting is that if you have your unique ID and other libraries’ IDs taking part in the open type, I believe you can generate a unique discriminant without possibility of collision.
But crytographic hashes are also an interesting approach to this problem, all interesting stuff