Michael Chirico

^ following the above comment, I'll close this & replace by a more focused issue extending `string_boundary_linter` for cases like `^static$`.

the former (and the latter since we like to apply our own linters)

I think there are many such cases where `extraction_operator_linter()` is giving false positives (e.g., `[[` method is not defined for the object, or it really is intentional to maintain the...

Perhaps a better choice is to add parameters: `allow_single_extraction` and `allow_dollar_extraction` that toggle which of the usages are linted.

To me personally, I would rather someone just use base syntax than make their code so complicated: ```r a[a[[col]] == b], ] ``` conveys this pretty unambiguously since `[.data.frame` doesn't...

IIUC the desired linter blocks _all_ plain symbol usage, i.e., everything must be .data or .env, which IINM _could_ be done statically

if we lint T->TRUE and only block on SYMBOL (not SUMBOL_FUNCTION_CALL), we're down to only needing .env$my_fun. possibly that could be eliminated through a carve out for base/purrr mappers. inverse...

Is there any reason to attempt running linters if `get_source_expressions()` returns an error? ```r file

Bumping to 3.1.0... the change to just not attempt linting for syntax errors feels like a big enough behavior change, and the current HEAD behavior (somewhat cryptic error, but _does_...

@ywwry66 can you confirm you're on the latest dev version?