Error message not that helpful in `labs()` if set to `element_blank()`

[olivroy]

I used to do this to remove axis labels

ggplot(mtcars, aes(cyl, mpg)) + geom_point() + labs(x = element_blank())

With the new ggplot2, I get the new warning.

#> `label` cannot be a <ggplot2::element_blank> object. 

The warning isn't that helpful. Took me a while to figure it out in a big plot construction.

Turns out I just have to use labs(x = NULL) instead.

I will change that everywhere in my code. But the problem comes when I use ggplotly().

ggplotly(ggplot(mtcars, aes(cyl, mpg)) + geom_point() + labs(x = element_blank()))
#> Erreur in as.vector(x, "character") : 
#>  cannot coerce type 'object' to vector of type 'character'

I wonder if that's an issue that should be fixed in ggplot2 (better warning), plotly (work with this), or my code. Possibly all 3, but I guess we can wait for more reports before taking action. I will update my code to get rid of element_blank() in the labs() calls.

Research notes
Changes occured in #6364

https://github.com/tidyverse/ggplot2/blame/961b194941380faa77addafd9d9f46b2d105ba8e/tests/testthat/_snaps/theme.md#L124

[teunbrand]

I agree that the warning isn't helpful: it should be an error instead.
I don't think it is right for ggplot2 to police what {grid} accepts as display text.
The warning is a backward compatibility measure to not break every package that put theme elements as labels.
It will be removed in favor of an error at some point in the future once packages have been afforded some time to change.
IMO, plotly is handling this correctly and it is ggplot2 who should handle it the same way (in a while).

[teunbrand]

So to make this error message more helpful, we'd have to track where theme elements as labels would be declared. This is not straightforward because it can be in labs(), scale functions or guide functions. It can be because a theme element is supplied directly or, when using a function as label, as its return value. It is hard to track provenance.

Next, there may be legitimate reasons why strange objects, like theme elements, end up as labels. While rendering element_text() strictly requires strings/expressions; other custom elements may use arbitrary input. This makes it a bad idea to police input errors at the point of ingestion.

In element_text() all these objections have resolved, which is why it can throw this warning unambiguously. In addition, the ... documentation in ?labs does not suggest that element_blank(), or other theme elements, are valid input.

In short, throwing a more informative error requires a lot of bookkeeping. Bookkeeping adds maintenance burden. Furthermore, valid input is documented. For these reasons, I think it is not worth improving the warning and I'll close the issue.