You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At root, if we're writing functions taking regular expressions with re_matches() as a backend, it's hard to anticipate whether the user will use capture groups (or vice versa), and it can be hard to remember the need to branch the follow-up code depending on whether we received a data.frame.
Much better IMO to offer a path for type-stability directly in the re_matches() API (much like simplify=FALSE in *apply world). Maybe ignore_capture_groups (FALSE by default), then we can write code with ignore_capture_groups=TRUE to guarantee a logical return.
The text was updated successfully, but these errors were encountered:
More than once now, we've run into an issue caused by type-instability of
re_matches()
output (logical vector vs. data.frame).r-lib/lintr#196
r-lib/lintr#2287
r-lib/lintr#2678
At root, if we're writing functions taking regular expressions with
re_matches()
as a backend, it's hard to anticipate whether the user will use capture groups (or vice versa), and it can be hard to remember the need to branch the follow-up code depending on whether we received a data.frame.Much better IMO to offer a path for type-stability directly in the
re_matches()
API (much likesimplify=FALSE
in*apply
world). Maybeignore_capture_groups
(FALSE
by default), then we can write code withignore_capture_groups=TRUE
to guarantee a logical return.The text was updated successfully, but these errors were encountered: