Consider using additive `2d` and `3d` features
Hi-
I struggled with the same issue when Bevy changed its renderer, to ensure both 2D and 3D could be used for bevy_hanabi. Initially the code had some 2d and 3d features, but they were mutually exclusive, which is equivalent to what you have now in bevy_debug_lines with a feature and its opposite.
For bevy_hanabi this caused a number of issues:
- By default users have to choose, even before they know anything about the crate. This is not nice.
- If you set a default, like you did here with
3d, then this hinders discoverability; users might miss that feature flag and end up not being able to use the crate in 2D and get confused, and either log an issue or eventually abandon and consider the crate is broken.
- If you set a default, like you did here with
- Obviously, with that setup you cannot use both 2D and 3D. This was already a problem for
bevy_hanabiwith particles, but forbevy_debug_linesthat seems like an even harsher limitation, as games/apps commonly have a mix of 2D and 3D, and you don't want to find yourself having to choose which one you can line-debug and which one you cannot. - Having a mandatory feature doesn't play nice with some tooling like
cargo testor code coverage. Being able to use--all-featureson the other hand, and covering all codepaths that way, is quite handy.- Related, but more minor, is the fact the official Rust guideline for features is to be strictly additive. So in theory having some codepath activated by the absence of the
3dfeature is breaking that rule. I know many crates break it anyway, and in particularno_stdbreaks that idiom, butcargoand other tools are working under that assumption of features being strictly additive, and sometimes things break if that's not the case.
- Related, but more minor, is the fact the official Rust guideline for features is to be strictly additive. So in theory having some codepath activated by the absence of the
Eventually the solution was to support both 2d and 3d features additively, each plugging into the appropriate renderer (see here for details). I think that's a nicer approach, and it's not that much more complicated to implement.
Thanks!
Thanks for the suggestion!
Yeah, I really hate the way we do 2d/3d separation at the moment, and I'm looking at anything I can do to make it... not crap.
Will definitely look into doing this when I have time.