Feat: Sets Spread Across An Entire Crate

[mcmah309]

Some users may find it useful to allow sets to be spread across the entire crate. Due to the way Rust works this is not possible without a different approach.

Proposal

• Add a feature flag - code_gen. This flag will enable an error_set_part! macro.
• Create a build runner to run in build.rs that scans all files for error_set_part! definitions and combines all definitions in a file like error_set.rs with a single error_set! macro.
• Since error_set_part! can know the name of each error type it needs and the output location is constant, it can evaluate to import the correct enums from this file. e.g.

error_set_part! {
    Error1 = ...
    Error2 = ...
}

->

use crate::error_set::Error1;
use crate::error_set::Error2;

[DavidMedin]

Would each crate that uses error_set then need to add or modify their build.rs, or would error_set have a build.rs that will implicitly be used?

[mcmah309]

To use this feature, each crate would have to add a line to build.rs

[mcmah309]

This feature is now on master if people want to start using and testing it. Happy to hear feeback. See https://github.com/mcmah309/error_set/tree/master/test_crates/error_set_part

[Jaltaire]

@mcmah309, the biggest issue I foresee re: https://github.com/mcmah309/error_set/tree/master/test_crates/error_set_part is that it precludes supporting multiple disjoint error sets within a single crate (that we don’t want to be combined).

Perhaps this is not a common issue for most people using error_set in a standard way, but there are times where I do want disjoint error sets within the same crate, so having a build.rs which identifies error set parts and statically joins them all into a single error set may not be ideal for my use case.

Might it be possible to name/tag the error set parts in some way, such that only those marked with the same name / have the same tag are grouped together?

[mcmah309]

One could still use the regular error_set! macro for cases that you don't want joined into the crate level error set (error_set.rs). But are you saying you'd like to have multiple error_set_part! scopes? Yes it would be possible to support this, but more ugly and I didn't think this would be desired e.g.

error_set_part!{ "scope_id",
...
}

Or

#[scope(scope_id)]
error_set_part!{
...
}

The latter could be possible as of 1.88, since macros now have access to invocation location information.

Either way, the default error_set.rs is probably desired if not specified?

[Jaltaire]

@mcmah309, precisely, I would like to have multiple error_set_part! scopes, and presumably have a default error_set.rs (or similar output file) if scope-less.

I also particularly like this syntax (or something comparable):

#[scope(scope_id)]
error_set_part!{
...
}

as this appears similar to approaches in other libraries (e.g., serde).

Admittedly, part of my interest in having this is because I do “abuse” error_set to create enum unions for non-error types (e.g., Response types across axum handlers), and I do envision times where having disjoint enum unions distributed across a crate would be helpful for my use cases.

To this end, if there is any way to configure the output file name, I would further appreciate it. 🙂

[mcmah309]

presumably have a default error_set.rs (or similar output file) if scope-less.

Yes and I imagine the scope_id would be the name of the output file in the crate root. e.g. #[scope(request_errors)] -> request_errors.rs

part of my interest in having this is because I do “abuse” error_set to create enum unions for non-error types (e.g., Response types across axum handlers), and I do envision times where having disjoint enum unions distributed across a crate would be helpful for my use cases.

Ah interesting. I actually thought about doing this and I created the declare crate for this reason, but then put that idea on hold. It would be like

declare::error_set!{

}
// Or
declare::set! {

}

I abandoned it because I didn't know if people had uses outside of errors and If I went this route, I imagine the error_set crate would just become a re-export of the declare macro.

Having this in this crate pains me though

error_set::set! { // Not actually an error

}

since "error" is in the name and the set is not actually an error.

[Jaltaire]

Yes and I imagine the scope_id would be the name of the output file in the crate root. e.g. #[scope(request_errors)] -> request_errors.rs

This sounds great.

I abandoned it because I didn't know if people had uses outside of errors and If I went this route, I imagine the error_set crate would just become a re-export of the declare macro.

I'm certainly biased, but I would very much appreciate a generalized version. 🙂

In the meantime, I'm just using a lot of #[skip(Error)].