FWIW, very excited to see something like this happen! {ggdist} has its own boilerplate generation for geoms and stats if you are looking for a comparison point: https://github.com/mjskay/ggdist/blob/master/R/abstract_geom.R

Besides reducing maintenance issues I have also moved a lot of documentation into it, so now comprehensive docs of aesthetics and computed variables are generated automatically. Has made my life quite a bit easier.

Thanks Matthew, it is cool to see that other people have also run into (and solved!) 'there should be hidden parameters' problem I got stuck on as well ^_^ It is interesting (in the good way) to see you opted for a ggproto approach, but I guess this might help coordinate various tasks at once.

I also recently was pointed to @corybrunson's https://github.com/corybrunson/ordr/blob/main/build-pre/build-layers.r, which performs a similar task as well.

Heh oh yeah, I also see your other PR landing on a very similar default_params solution to extra_params as well. I had to fix that because it made it very hard to create a class hierarchy of geoms without constantly copying a bunch of boilerplate param definitions across geoms.

If this gets combined with other changes, depending on how far that goes in the direction of breaking changes (including the potential for introducing breaking changes to solve other longstanding problems), one solution you might consider is introducing an alternative base Geom class people could inherit from to "opt in" to the newer, cleaner interface.

Alright, stats are covered too now. The method is similar to make_constructor.Geom but fixes the layer(stat) instead of layer(geom) and leaves geom is a user-specified argument rather than stat. Per discussion, the main function is now called make_constructor().

For Stats, I sometimes had to hide variables, which I did through the make_constructor(omit) argument. Mostly for two reasons.

1. It was a computed parameter in Stat$setup_params() or the parent Stat$compute_*() method. These should not be exposed to users, even though they technically could pass these arguments to ....
2. It was a parameter that a user could use, like stat_bin_2d(breaks), but was not exposed, similar to Better documentation of xseq for stat_smooth() #5246.

I hide both these cases, but for (1) we might consider a mechanism for explicitly prohibiting these arguments and for (2) whether such parameters should be exposed. This is outside the scope of this PR I think.

I also see your other PR

This doesn't really narrow it down I'm afraid😅

how far that goes in the direction of breaking changes

I don't plan on breaking too much here. This is mostly a convenience function, so I'm looking for a standardised solution. Instead of packing everything in these make_constructor() methods, I aim to pack ~80% of functionality in these methods and keep the current constructors with exotic logic as-is. I don't think it is worth it to code the geom_text() nudge/position logic into the make_constructor() method for example.

Marking this as ready for review as we decided we don't want a make_constructor() for scales