Michael Chirico

Oh @ywwry66 actually that's #763. This works: ```r x = lint("foo

yes... Q is what's the "right" fix. it could be the printing method, or lint(), or Lint(). I still don't know for sure.

FWIW I think we should ignore `str_interp()`, since it's marked as superseded: https://stringr.tidyverse.org/reference/str_interp.html Its successor, `str_glue()` should be treated same as `glue()` since it's just a wrapper: ``` stringr::str_glue function...

FWIW it should be pretty straightforward to implement a customized linter for your use case. I would take more convincing to support exceptions for the lintr version.

Please don't forget to add a NEWS item of this when it's done :)

Hi @LukasWallrich, not that `extraction_operator_linter()` is not a default linter, so it's not really a "recommendation". In fact we don't enforce this on ourselves: https://github.com/r-lib/lintr/blob/main/.lintr_new This is just an offered...

Thanks Indrajeet!!! 💪💪💪

FWIW, we have a linter for this already (slated for upstreaming eventually). Any ==TRUE/FALSE expression is linted. One tougher case is data.table subsetting, where the overloading of the `i` argument...

up to OP -- originally the requested linter is slightly different. but if this format is satisfactory they ok

That's fine, I don't think there's any rush for 3.0.2. Porting is mostly tedium to switch internal idioms to match lintr style, and more importantly reviewer bandwidth.