[Merged by Bors] - Fix some nightly clippy lints

[BoxyUwU]

on nightly these two clippy lints fail:

• needless_borrow
• unused_unit

[mockersf]

I think all the #[allow(clippy::unused_unit)] are due to all the macros for tuple running on tuples of size 0 which... are not actually tuples but just unit.
What would be the impact of fixing that so the macros start at 1?

[BoxyUwU]

• fn foo() would not be a valid system, not sure if this is actually useful or not but it doesnt seem harmful to allow
• () would not be a valid fetch making Query<()> invalid so we wouldnt be able to do filter only queries
• () would not be a bundle... which actually seems like a win :)

[mockersf]

so... I think we should stop considering unit to be a special case of tuples, have the macros start at 1, and only impl the relevant trait for unit

[alice-i-cecile]

so... I think we should stop considering unit to be a special case of tuples, have the macros start at 1, and only impl the relevant trait for unit

I agree with this.

fn foo() would not be a valid system, not sure if this is actually useful or not but it doesnt seem harmful to allow

I've used this for testing and debugging before, so I'd like to keep it.

() would not be a valid fetch making Query<()> invalid so we wouldnt be able to do filter only queries

I would also like to keep this.

() would not be a bundle... which actually seems like a win :)

Yeet this one.

[mockersf]

@TheRawMeatball mentioned that unit are actually tuples.

[BoxyUwU]

they are, i still think it makes sense to split out these impls though as the reason for having them is different than the impls for other tuples

[TheRawMeatball]

I'd disagree - having the tuple implementing ones also impl for the unit type is rather elegant imo, and I think we should keep them. IMO, to fix the lints, we should just add #[allow(clippy::unused_unit)] to these macros.

[cart]

I agree with @TheRawMeatball: a separate manual impl for unit is cumbersome / redundant / error prone. We should just suppress the lint for relevant impl macros (if there is no way to phrase the code to suppress the lint implicitly).

An example of an implicit suppression:

fn foo(_bar: T) {
  // bar isn't used and _ suppresses the unused lint
}

[cart]

() no longer a bundle

I'm cool with this

edit: im cool with this now that direct spawn() calls are a thing.
However this should probably be a separate decision that we shouldn't make in the heat of the moment. Lets suppress this in the best way we can and handle it later if anyone feels strongly about it.

() no longer a Fetch

This creates problems for both filterless queries and fetchless filters (because they both rely on () having a Fetch impl ... filters are a special case of Fetch). This should stay as-is.

fn foo() would not be a valid system

strong disagree. users should be able to create inputless systems (for things like printing messages)

[cart]

Sorry I added a new thought in the edit of my previous message, which probably should have been a new message so yall don't miss it.

[BoxyUwU]

imo () being a bundle never has a use case so having it implemented can only cause silent errors but im fine to table this for a different PR

[cart]

bors r+

[bors]

Pull request successfully merged into main.

Build succeeded:

• build-android
• build (nightly, ubuntu-latest)
• build (stable, macos-latest)
• build (stable, ubuntu-latest)
• build (stable, windows-latest)
• build-wasm (nightly, ubuntu-latest)
• build-wasm (stable, ubuntu-latest)
• check-doc
• check-markdown-links
• check-missing-examples-in-docs
• check-unused-dependencies
• markdownlint
• run-examples