tags.scm should probably recognize functions with string names on the LHS

[DavisVaughan]

Like "$<-.data.table" in data.table
https://github.com/Rdatatable/data.table/blob/4d42cdc4f73084390eccc589e726519556c1f8a1/R/data.table.R#L2257-L2264

Not sure exactly what we should tag as the @name, probably just the whole string including the string delimiters? I think if we naively drop the delimiters and use the string_content we could have issues in the case of "name \" with dquote" because you end up with this \ in the captured text that would have to be unescaped to get name " with dquote. Seems a little complicated.

Then again, maybe if it works better in the 99% case with string_content, we should just do that and be ok with problems in the 1% case?

[kevinushey]

I'm also on board with just using string_content. It also allows us to discount the delimiter, since these all do the same thing:

foo <- 1
"foo" <- 1
'foo' <- 1
`foo` <- 1

and it's more in line with the "truth", which is a variable called foo is created, regardless of its delimiters.

Not to mention, raw strings 😅

[MichaelChirico]

Yea, raw strings are a huge pain:

R"----------(why is this allowed?)----------" <- \(x) x

`why is this allowed?`(2)
# [1] 2

[MichaelChirico]

Probably a separate bug, but I notice there's no support for right-assigned functions:

(function(x) { x }) -> foo
foo(2)
# [1] 2

This is a monstrosity (in my ever-so humble opinion), but does come up in CRAN packages:

https://github.com/cran/symbol.equation.gpt/blob/b9c5722f84da9b3464baef121ebd6c0cd8f26689/R/aaa.R#L15-L22

Note that due to operator precedence ()-wrapping is required.