Avoid allocations for Monoid instances where possible

[bplommer]

Prompted by http4s/http4s#6712, which locally caches a particular Monoid[List[*]] instance - the issue is a generic one so it seems better to apply this optimisation here.

There are other cases where this kind of change could be made too but I wanted to get feedback before doing any more work on it.

[armanbilge]

Suggested change

	private val singleton: Monoid[List[Any]] = new ListMonoid[Any]
	private[this] val singleton: Monoid[List[Any]] = new ListMonoid[Any]

[bplommer]

I thought private[this] was in line for deprecation in Scala 3?

[armanbilge]

private[this] and private are effectively the same in Scala 3. But it still means in something in Scala 2.

[armanbilge]

Do we really need an object for this? can we just put it alongside the implicit def.

[bplommer]

Maybe not - I did it for consistency with the other cases but happy to change it.

That also raises the question of whether to go ahead with adding the companion objects in the other cases. What do you think?

[armanbilge]

That's a good question. In those cases the monoid class was publicly exposed. In this case the object is private, seems to be created unnecessary indirection

Tbh I just don't think it's that valuable—if users directly want the monoid instance can't they just grab it from the implicit def instances or whatever?

[TimWSpence]

I think you run into bincompat issues if you put it on the trait. Or at least I did in #4313

[armanbilge]

You are right, but should be fine if either the trait is private/sealed or it's actually an (abstract) class 😛

[TimWSpence]

Ah gotcha 👍 Whereas ListInstances is a public trait

[armanbilge]

Yeah, for those we will have to store the instance elsewhere 👍

[TimWSpence]

OK I've made the changes above. How do I actually add the commits to this PR? 😅 Do I need push access to Ben's fork or can I push to some magical branch on the typelevel repo?

[armanbilge]

@TimWSpence you can just open a new PR based on this branch.