unnecessary_parenthesis should forgive conditional operator and equality

[oprypin]

This came up in a Google-internal discussion as something that some people like to write and would hate the linter to drop the parentheses for them.
As such, it's a blocker for internal adoption.

I would like to introduce these rules:

• (a ? b : c) is always OK
• (a == b) and (a != b) are OK in assignment-like and return-like statements.

---

Examples of replacements that I wish didn't happen (copying my own comments from that discussion):

•   Foo(String? name) : name = (name == null || name.isEmpty ? _generateNodeName() : name),
    Foo(String? name) : name = name == null || name.isEmpty ? _generateNodeName() : name,

  This is a downgrade because my mind jumps to read it as (name = name == null || the rest).

•       node.hasValue = (value == null);
        node.hasValue = value == null;

  I dislike the fact that Value = value jumps out at me so strongly. Part of it might just be an issue of distance because == is just longer and makes the precedence appear lower than =. The other part is that I want to use the parentheses to stress the fact that I'm assigning the result of a boolean expression, not assigning "value with some other code trailing behind it".

---

I will immediately open a pull request that would address this issue.

[oprypin]

And one more example of an unfortunate replacement:

•   [a, ...(x > 0 && foo != null ? foo : [])]
    [a, ...x > 0 && foo != null ? foo : []]

[bwilkerson]

I agree with the desire to allow parens around conditional expressions, but I'm not fully convinced by the argument that we should allow extra parens on the right of an assignment or a return. In any case, I'd like to leave some time for community feedback on this proposal before landing the PR to make the change.

[bwilkerson]

I have to wonder whether we want to keep special casing this lint to try to fit some not-yet-defined criteria or whether we want to deprecate the lint because of all the false positives that appear to be associated with it.

@pq @srawlins

[srawlins]

I'm happy to keep special casing it. We want to enforce it internal to Google, where data of violations is helping to decide which parentheses look unnecessary and which improve readability.

If we chose to delete it though, and let internal-to-Google resurrect it there, I'd be fine with that too.

[srawlins]

I have to wonder whether we want to keep special casing this lint to try to fit some not-yet-defined criteria

I think the criteria is defined here. It's soft but I think that's ok, and I still consider it to be defined. https://dart-lang.github.io/linter/lints/unnecessary_parenthesis.html

[pq]

As a general rule, I think every special case kind of erodes the value of a lint and this one is pushing a limit IMO. I wonder if there's a way to re-think this to be a little less opinionated, firing in fewer places where none of them is controversial, at the cost of passing over places that would require heuristics. I guess I'm asking, can we make it less soft, more precise with a more limited scope.

[oprypin]

People really have looked over violations in detail and this is the only exception that came up.

There won't be any interest in reworking this rule because it's already really great otherwise.

It's true that this particular exception is fuzzy, but I think the core of the lint is solid, it's just the implementation that needs to have a lot of branches because the AST doesn't have a generic utility for reporting which constructs have parentheses and where.