`too_many_arguments` should ignore functions called `new`

[sgrif]

The recommendation provided by that lint is to group the arguments into a new type, and should probably ignore functions that are almost certainly a constructor for a new type.

[Arnavion]

Related: nrc/derive-new#13

[richard-uk1]

I'd argue that if there are that many fields, it makes sense to use a Builder, avoiding a single function call.

[llogiq]

Perhaps we can special-case the lint message?

[workingjubilee]

The Builder pattern is a way to gradually build data, it is not necessarily useful to increase abstraction when all the data is known and already present.

I believe this can be changed in the following match:

rust-clippy/clippy_lints/src/functions/too_many_arguments.rs

Lines 19 to 37 in 6ae0835

	// don't warn for implementations, it's not their fault
	if !is_trait_impl_item(cx, hir_id) {
	// don't lint extern functions decls, it's not their fault either
	match kind {
	intravisit::FnKind::Method(
	_,
	&hir::FnSig {
	header: hir::FnHeader { abi: Abi::Rust, .. },
	..
	},
	_,
	)
	| intravisit::FnKind::ItemFn(_, _, hir::FnHeader { abi: Abi::Rust, .. }, _) => check_arg_number(
	cx,
	decl,
	span.with_hi(decl.output.span().hi()),
	too_many_arguments_threshold,
	),
	_ => {},

For the FnKind::Method variant we can check the Ident field to see if it is new, see:
https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/intravisit/enum.FnKind.html

[richard-uk1]

I'd argue that if there are that many fields, it makes sense to use a Builder, avoiding a single function call.

4 years down the line, I'd now disagree with myself, and say that constructors are sometimes better than builders.

[camsteffen]

I can see how it might be deemed necessary to have a lot of args for a constructor. But it is still a code smell generally speaking, the lint is not "wrong", and so I don't think a special case should be added. You can allow on the constructor. You could also consider refactoring by grouping some fields into structs.