About the name and the default value of rename_aes

[yutannihilation]

@thomasp85
Sorry for bothering you. Re-reading #3672, I found I don't have clear answers to the following points. Can we discuss here?

1. Why is the default value of rename_size FALSE? I'm afraid it would feel a bit inconsistent that the extension packages that don't catch up with this change would behave differently, while we are very careful not to introduce breaking changes on ggplot2 itself by setting rename_size = TRUE everywhere necessary. What about
   a. using rename_size = TRUE by default for the first release, or
   b. making the default value of rename_size as an option or an edition? In this case, the user can choose the behavior they prefer, and the developer can use rename_size = FALSE (or TRUE) if they think it's inappropriate to expose it as an option.
2. Can we have another word than "rename"? It seems "rename" sounds like the original one is removed (c.f. Add rename_size=TRUE to GeomSf, GeomCrossbar, GeomPointrange, and GeomSmooth #4884 (comment)), like dplyr's rename(), while rename_size = TRUE actually keeps the size.

[thomasp85]

1. Because setting rename_size = TRUE will trigger a deprecation warning if size is used. I don't think anything is gained by doing this any softer - at some point there will have to be a switch and it might as well happen now when the change is in the minds of the extension developers. I think history has shown that our extension developers are quite quick to catch up. Using an edition sets a bad precedence for any breaking change to warrant that.

2. I'm not married to the name, but I do think it communicates the intend of the setting quite well, i.e. it opts in to the renaming. The fact that the old aesthetic is kept is an implementation detail of sorts

[yutannihilation]

Thanks. For point 2, I got it. Sorry for the noise.

For point 1, I think you are right, but let me think for a while before closing this issue. It seems the part of my confusion was because I didn't see any deprecation warnings when playing with geom_sf() or geom_pointrange().

[clauswilke]

@thomasp85 @yutannihilation Do we have a guide for extension developers telling them what exactly they have to do to ready their packages for this change?

[yutannihilation]

I guess this is the guide, and probably this will go into the release blog post?

https://twitter.com/thomasp85/status/1537024892293599235

[yutannihilation]

Ah, but ideally we should tell them before the release, so the release blog post might be a bit too late?

[clauswilke]

Perfect, thanks. For some reason I rarely see Thomas' tweets anymore. I don't know what Twitter does these days. Even though my timeline is "Latest Tweets as they appear" it feels to me I'm seeing a curated feed where some stuff is simply missing.

[yutannihilation]

Really? In my case, for some reason, the Twitter algorithm always emails me whenever Thomas tweets about R :)

[clauswilke]

Yeah, who can understand what's going on there. In any case, I think it's important to be aware that tweeting something is in no way a guarantee that people actually see it.

[yutannihilation]

Okay, I'm still feeling it might be a good strategy to trigger a deprecation warning where possible, but I got convinced with this part

history has shown that our extension developers are quite quick to catch up

so I think I can close this issue now. Thanks for clarifying!

[thomasp85]

Regarding a guide, we will def make a good guide to help extension developers and it should be available before release. The tweet was mostly to make it apparent to those that saw the announcement that it was pretty easy to support

[yutannihilation]

Sounds good!