-
Notifications
You must be signed in to change notification settings - Fork 187
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Does str_c no longer coerce non-characters to character as of 1.5.0? #510
Comments
Do you have a reprex? library(stringr)
str_c(1:3)
#> [1] "1" "2" "3"
str_c(TRUE, FALSE, TRUE)
#> [1] "TRUEFALSETRUE"
str_c(1 + 2i, "x")
#> [1] "1+2ix" Created on 2023-08-04 with reprex v2.0.2 This is already more generous that what is documented, which specifies that the elements of |
I did a bit of testing after your reply and it looks like it's not non-character vectors writ large, but a subset of them. My use case was with tryCatch({
length(foo)
},error=function(e){
str_c("this will error",e)
}) > rlang::last_trace(drop = FALSE)
<error/vctrs_error_scalar_type>
Error in `str_c()`:
! `..2` must be a vector, not a <simpleError/error/condition> object.
---
Backtrace:
▆
1. ├─base::tryCatch(...)
2. │ └─base (local) tryCatchList(expr, classes, parentenv, handlers)
3. │ └─base (local) tryCatchOne(expr, names, parentenv, handlers[[1L]])
4. │ └─value[[3L]](cond)
5. │ └─stringr::str_c("error", e)
6. │ └─vctrs::vec_size_common(!!!dots)
7. └─vctrs:::stop_scalar_type(`<fn>`(`<smplErrr>`), "..2", `<env>`)
8. └─vctrs:::stop_vctrs(...)
9. └─rlang::abort(message, class = c(class, "vctrs_error"), ..., call = call) |
Ah ok, as the message states, |
It is unfortunate. All of the major paste-alikes follow the same pattern: Concatenate strings as-is, and coerce non-strings (more or less) to be a string as-printed. This doesn't just work for vectors like numerics, logicals, and datetimes, but also pretty much anything a reasonable user would think could be treated as text.
I get that I'm arguing with the de facto king of R here but I urge you to consider that even the developers of a significantly advanced R package, power users who know the inner workings of R and metaprogramming, were blindsided and stumped by this. Objectively what happened here was an unannounced break with language-wide established behavior, that isn't documented, that isn't consistent, and that breaks other things downstream puzzling even very experienced developers. If rolling back and giving a deprecation warning isn't an option I think at minimum the documentation should be updated to make it clear |
I've been using str_c as part of a shortcut to dump tryCatch errors into text popups in Shiny for years now and after updating to 1.5.0 it appears that's broken now. Other packages depending on Stringr such as SPATA2 also appear to have been impacted by this.
The thing is I don't remember any console warnings of an upcoming breaking change, it's a significant break with expected behaviour based on the other major paste-alikes, and I can't find any mention of this in the function reference. The release notes for 1.5.0 do vaguely mention "many more arguments" but don't confirm what was involved and as mentioned the manpage doesn't mention this stringent requirement.
Was this one of the breaking changes? And if so is there any chance of this being temporarily downgraded back to a warning with the notification that str_c will be breaking significantly from traditional expected paste-like behavior in the near future?
The text was updated successfully, but these errors were encountered: