Unused generic parameters should not be hard compiler errors

IIRC this has been rust behavior from the very start, so perhaps it is sacrilegious to suggest it but I don't believe that unused generic parameters on enums, structs, and traits should be a hard error, and I do not see any reason why they need to be instead of a warning.

I often find myself omitting a member from a struct that was the only instance of a generic parameter or lifetime being used to try something out. Yes, it's possible to use a phantom marker but that isn't the most ergonomic approach.

Is there a reason besides ideological purity why an unused generic parameter if implemented correctly in all references to the object must be an error?

e.g. I do not think there is actual technical reason (i.e. unsoundness or ambiguity) why the following code should fail to compile:

struct Foo<T> {
    bar: String,
    // baz: Vec<T>,
}

impl<T> Foo<T> {
    fn new() -> Self {
        Self {
            bar: String::new(),
            // baz: Vec::new(),
        }
    }
}

fn main() {
    let foo: Foo<()> = Foo::new();
}

While <T> is not used in the definition of Foo, all references to Foo (such as impl Foo and the instantiation site in main) handle it and the compiler could theoretically accept this (with lots of grimacing and complaining), no?

For reference, the following error is currently returned:

error[E0392]: parameter `T` is never used
 --> ./test.rs:1:12
  |
1 | struct Foo<T> {
  |            ^ unused parameter
  |
  = help: consider removing `T`, referring to it in a field, or using a marker such as `std::marker::PhantomData`

error: aborting due to previous error

(Originally filed as https://github.com/rust-lang/rust/issues/70792)

Start with the issue's example and current E0392 diagnostic, then review the Rust RFC process and the original issue linked in the description. Determine whether unused generic parameters should become a warning and define the required behavior for structs, enums, traits, implementations, and uses before proposing an RFC or implementation plan.