You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
However, we now have new operators like ??=. I use this in assignment expressions all the time to implement concise idiomatic caching. For example, here:
Splitting this assignment up into multiple lines would only:
Make it more likely for me to introduce bugs.
Make it harder to read.
Increase the code size (including minified code shipped to the end user).
It turns out that we use this pattern 43 times inside cubing.js. I do not want to change my use of ??= for this, so we disable the rule completely instead of introducing biome-ignore all over the project.
However, this means that if someone writes an assignment expressions with = this will not be caught.
Further, a lot of https://github.com/cubing projects use a common config and so for each project I have to make an individual decision — when does the project have enough ??= expression usage that I need to disable lint/suspicious/noAssignInExpressions for that project? I'm worried I'll be tempted to just make my life simple and ignore it for all projects, as much as I think that could allow a serious bug to slip in.
I'd like to suggest the following:
Scope lint/suspicious/noAssignInExpressions to unconditional assignment (=, <<=, +=, etc.).
Default to: error
Optionally: Deprecate and rename to lint/suspicious/noUnconditionalAssignInExpressions.
Introduce lint/suspicious/noConditionalAssignInExpressions for conditional (??=, ||=, &&=) assignment expressions.
Default to: warning
Even if both default to error, I'd get a lot of benefit from being able to configure these separately.
Alternatively, it would also be equally helpful for me if ??= on its own was split into a separate rule. Even in contrast to ||= and &&=, it has semantics that are much more tightly suited to cached initialization than the other operators — corresponding to patterns like OnceLock in Rust.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
https://biomejs.dev/linter/rules/no-assign-in-expressions/ originally stems from a time when the only way to use an assignment operator in an expression was
=
.However, we now have new operators like
??=
. I use this in assignment expressions all the time to implement concise idiomatic caching. For example, here:Splitting this assignment up into multiple lines would only:
It turns out that we use this pattern 43 times inside
cubing.js
. I do not want to change my use of??=
for this, so we disable the rule completely instead of introducingbiome-ignore
all over the project.However, this means that if someone writes an assignment expressions with
=
this will not be caught.Further, a lot of https://github.com/cubing projects use a common config and so for each project I have to make an individual decision — when does the project have enough
??=
expression usage that I need to disablelint/suspicious/noAssignInExpressions
for that project? I'm worried I'll be tempted to just make my life simple and ignore it for all projects, as much as I think that could allow a serious bug to slip in.I'd like to suggest the following:
lint/suspicious/noAssignInExpressions
to unconditional assignment (=
,<<=
,+=
, etc.).error
lint/suspicious/noUnconditionalAssignInExpressions
.lint/suspicious/noConditionalAssignInExpressions
for conditional (??=
,||=
,&&=
) assignment expressions.warning
Even if both default to
error
, I'd get a lot of benefit from being able to configure these separately.Alternatively, it would also be equally helpful for me if
??=
on its own was split into a separate rule. Even in contrast to||=
and&&=
, it has semantics that are much more tightly suited to cached initialization than the other operators — corresponding to patterns likeOnceLock
in Rust.Also see: #7192 (comment)
Beta Was this translation helpful? Give feedback.
All reactions