Enhancement: [prefer-literal-enum-member] Allow nested bitwise when using the `allowBitwiseExpressions` option about typescript-eslint

[bradzacher]

I did misunderstand yeah.
But I still stand by what I said - it's still relevant!
We're in a very small intersection of codebases that need functionality like this.

[kirkwaiblinger]

Thinking more about this, I would amend my previous comment (again!), because I can fathom a codebase that needs 1 << 0 (i.e. numeric literals) to work but does not need A | B (nonliterals) to work, since it would make sense to just set a bunch of independent enum members to different powers of two, without having any named combinations thereof, and then do bit manipulations at the usage sites for flags. In fact, (contrary to my previous assertion) this may be the more prevalent usage, but I could see it going either way.

I cannot fathom a codebase which needs A | B to work but wouldn't also expect A | B | C to work.

Keep in mind, #9114, whose backing issue (#7763)'s express purpose (noted also @JoshuaKGoldberg's acceptance comment #7763 (comment)) is to support self-referential enum bit operations, was merged literally yesterday. I think that issue is basically just not resolved at all without A | B | C support. If we don't include support for it, a different feature has been born, which is to support non self referential flags, with incidental support for trivial self-referential flags (that I would consider a bug against that feature!).

Here's my personal thoughts, feel free to differ

approach	satisfactory in Kirk's opinion?	effort to implement
Leave as is	Not satisfactory; known half-baked feature on day 1 when it releases next Monday	Literally None
Remove the option altogether	Not satisfactory; we just merged it yesterday. (Would be a different story if it was a feature that had existed for a long time but no one cared about, and we decided to deprecate it)	Trivial
Remove support for nonliterals in the bit operations	Acceptable; only ships a coherent, complete feature, albeit not the one agreed to in issue request. (probably should also be reduced to only allowing << for bitflags if we did go this route)	Slightly more effort, but still trivial
Add support for arbitrarily nested bit operations	Best outcome	Easy. Recurse on left and right operands of binary expressions. Marginally more difficult than it was for me to format this table

[bradzacher]

My 2c - it's such a rare usecase to do something like this that I don't think it's worth the effort to introduce such an option.

Few codebases will use bitwise enums by themselves - let alone bitwise enums that are self-referencing.

[kirkwaiblinger]

My 2c - it's such a rare usecase to do something like this that I don't think it's worth the effort to introduce such an option.

Few codebases will use bitwise enums by themselves - let alone bitwise enums that are self-referencing.

@bradzacher There might be a misunderstanding? I think that's an argument against #7763, but not this issue. The option already exists (has just been created), but with a bug.

enum E {
  // The primary reason you would ever write these is to permit self-referential constructions like AandB or AandBandC
  A = 1 << 0,
  B = 1 << 1,
  C = 1 << 2,
  // This is allowed, and is the entire stated reason for https://github.com/typescript-eslint/typescript-eslint/issues/7763
  AandB = A | B,
  // This flags, but should be allowed if the previous one is allowed.
  AandBandC = A | B | C,
  ~~~~~~~~~
}

+1 to allowing arbitrary bit manipulations so long as the operands are numeric literals or other enum members. Numeric variables maybe should be allowed too to support masks?...but that seems problematic since it would require type information, which is hard to justify for a rule whose primary use case is purely syntactic.

EDIT
Actually, it's probably a TS error to supply a non-numeric variable to a bitwise operation anyway, so we might be able to get away with allowing nested bitwise operations on numeric literals, any variables, and enum members.

EDIT 2
+1 to allowing arbitrarily nested bit manipulations on whatever operands are currently permitted by the implementation.

[Josh-Cena]

I agree that D = A | B | C should be allowed. I don't think D = A | B & C should be allowed. Neither should D = (1 << 10) | B.

[kirkwaiblinger]

Yeah, I don't have enough experience with using complicated flag enums to know whether there's a good use case for many other operators. It does seem like 1 << 2 and A | B | C | D are probably the vast majority of the use case. Feel like it wouldn't hurt to err on the side of being permissive rather than too restrictive either though. No strong feelings on the resolution to those details 🤷‍♂️ , except that deferring to whatever operands the rule currently supports seems least controversial.