Open Sword-Smith opened 6 months ago
Does this trait requirement interfere with anything? Do the
#[derive(Debug)]
interfere with anything? It is common practice to#[derive(Debug)]
wherever possible, unless there's a good reason not to do so, of which I can find few and none that seem to apply here.
I see two arguments for removing Debug
Debug
trait constraint on fields in snippet structs that implement BasicSnippet
In the end, this is your codebase; do as you see fit.
I return to my first question; does the trait bound interfere with anything?
- I'd be very surprised if that additional workload was significant.
In the end, this is your codebase; do as you see fit.
I guess my opinion is more based on aesthetics and how I think you should inspect values of this type. Aesthetically I don't like to impose trait bounds that are not needed, and I think that you should inspect the the type of a snippet through its entrypoint name, not through its debug output.
If that is the case, then how about the following?
impl Debug for dyn BasicSnippet {
fn fmt(&self, f: &mut Formatter<'_>) -> std::fmt::Result {
write!(f, "{}", self.entrypoint())
}
}
This would also allow the #[derive(Debug)]
on the various types to stay in place.
Your suggestion works. But I should also like to point out that no Debug
derivations are removed with this PR, it's only the requirement that is removed.
What about removal of line 35 in all.rs
, line 31 in filter.rs
, line 83 in inner_function.rs
, and line 37 of map.rs
?
What about removal of line 35 in
all.rs
, line 31 infilter.rs
, line 83 ininner_function.rs
, and line 37 ofmap.rs
?
You're right. It got removed from higher-order snippets.
Does this trait requirement interfere with anything? Do the
#[derive(Debug)]
interfere with anything? It is common practice to#[derive(Debug)]
wherever possible, unless there's a good reason not to do so, of which I can find few and none that seem to apply here.