How to move forward?

[NobodyXu]

Sorry that I completely forgot this crate since I'm busy at other stuff!

I was going to do proc-macro until something else chips in.

[NobodyXu]

Right now I'm thinking if there's anyway to simplify it, because writing proc-macro is really painful way of doing it... It's a shame that rust has no reflection to simplify it.

[NobodyXu]

Also, very often, different error types might have the same error: e.g. io::Error that is common and often seen among the codebase.

For the 'anyhow'-like part in this crate, I think common types should be easily access... which makes it more similar to anyhow?

[Byron]

I mean, if you found some time to keep sketching and prototyping on this crate, that would be fantastic!

I don't know where I wrote something about the purpose of this fork, but to summarise:

• it's compatible to thiserror syntax so it can be swapped in
• it allows crates to have a stable API even in the light of changes to what errors can be returned. Such a crate will remain stable as long as variants are only added.
• it stores data efficiently by default to avoid huge error structs (much like anyhow), while having a way to visualize the tree of possible errors while making it possible to introspect errors. Ideally, there is a stable way of accessing parts of the error tree and get the data within it.

I hope that makes sense, but in a way it's a possible solution to the 'how to get thiserror for stable APIs' while making it easier to introspect errors (and this is what I am thinking about).

It's quite notable that the current way of introspection has the advantage that one cannot miss added error variants that might be important for what one tries to introspect. Maybe being able to visualize all possible errors in the tree, which is impossible right now), would at least help to on-demand figure out what one might be missing to learn something about an error.

Alternatively, maybe there could be a notion of 'tagging' errors. So libraries can provide easy-to-find tags that tell something about the error at hand.

And lastly, the error produced should be 'one and the same', so it's much like anyhow, but with a lot more metadata inside for better introspection. And of course, the library producer should be forced to spell out all possible errors as a form of documentation.

Of course, I don't know if any of this makes much sense, but please feel free to ask or share your ideas on how to solve the problems that this tries to address.

(it would be so exciting if this could work out, having a 'next-gen' error crate would be big)

[NobodyXu]

Thank you!

Yeah I think it makes sense, it's mostly just proc-macro which is giving me a bit headache before.

I need to find some time to continue on this.

[NobodyXu]

My initial thoughts on how to do the proc-macro, is to generate the name from the crate name + enum name + variant.

Crate name can be obtained by:

    let crate_name = std::env::var("CARGO_PKG_NAME").unwrap();

[Byron]

Yeah I think it makes sense, it's mostly just proc-macro which is giving me a bit headache before.

Yes, proc-macros aren't anything I like either, and thus far I managed to avoid it. Then I think at some point, one will have to learn it. My plan here is to tackle this once it's the last thing needed to be able to make gitoxide stable.

My initial thoughts on how to do the proc-macro, is to generate the name from the crate name + enum name + variant.

Apologies, I don't think I follow.

[NobodyXu]

My initial thoughts on how to do the proc-macro, is to generate the name from the crate name + enum name + variant.

Apologies, I don't think I follow.

I was thinking about how to generate the unique name for each error variant.

But I just realise that you could define the same enum name in different module as well...

So I think we need std::any::type_name, though I don't think it guarantees unique name, espeically when dynlib is considered.