Possible unintended behaviour of invert_match about stringr HOT 3 CLOSED

I have this in the docs for str_locate():

#' Vectorised over \code{string} and \code{pattern}. If the match is of length
#' 0, (e.g. from a special match like \code{$}) end will be one character less
#' than start.

Maybe it needs to be repeated in invert_match()? Or possibly invert_match() should be documented in the same file as str_locate()

from stringr.

If, as I understand, invert_match() is only intended for use with str_locate[_all] then maybe the documentation should be merged. Either way, I think it should be explicitly stated that the rows do not necessarily represent a "non match"
The Value section of the invert_match help says it returns a "numeric match giving locations of non-matches". This doesn't seem quite right; I wouldn't have said that there was a non-match between the two Ls in "HELLO".
As long as the user is made aware that there will be results that do not necessarily represent non-zero strings, (but perhaps you can word it better than that ;) ), they can take action on removing, if desired, those rows from the matrix.

from stringr.

Thanks for filing this bug report! Unfortunately since it doesn't seem to affect many people, and given that 7 years have elapsed since it was first filed, it's clear we don't have the development resources to fix at this time. It's our policy to close such issues to help stay focussed on the biggest problems, but the issue is still indexed by google, so if other people hit it, they'll be able to find it, and we can consider reopen it if it turns out to be a common problem. Thanks for reporting and I'm sorry we couldn't help more 😞.

from stringr.