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
One of the things that always bugged me about JS and tends to cause bugs of various sorts (just had another one last week) is the boolean coercion that happens in if clauses or when using boolean operators like || or ?:.
Here is an example:
var predicate = () => false;
if (predicate)
alert("true branch");
else
alert("false branch");
This will compile without issue and always end up executing the true branch, because the developer merely referenced the predicate function instead of calling it.
Another example (this time simply bad code):
function test(optionA: string, optionB: number)
{
// Set defaults if none provided
optionA = optionA || "[None]";
optionB = optionB || 1;
alert(`${optionA}, ${optionB}`);
}
test("", 0)
Empty string and zero get converted to false and the defaults get assigned even though possibly valid values were provided.
Having a compiler option that prevents implicit conversions like these would easily prevent some bugs. This changes nothing about the emitted code and would be an optional type safety measure like noImplicitAny, so i do not think there would be many implications to worry about.
The text was updated successfully, but these errors were encountered:
One of the things that always bugged me about JS and tends to cause bugs of various sorts (just had another one last week) is the boolean coercion that happens in
if
clauses or when using boolean operators like||
or?:
.Here is an example:
This will compile without issue and always end up executing the true branch, because the developer merely referenced the predicate function instead of calling it.
Another example (this time simply bad code):
Empty string and zero get converted to
false
and the defaults get assigned even though possibly valid values were provided.Having a compiler option that prevents implicit conversions like these would easily prevent some bugs. This changes nothing about the emitted code and would be an optional type safety measure like
noImplicitAny
, so i do not think there would be many implications to worry about.The text was updated successfully, but these errors were encountered: