If you use a double NOT ~~"foo" you will always get a finite int32 value... which is useful when you can use 0 as a "default" representation. For that matter, all bitwise operations will coerce a value to an int32 representation. Which is something to be aware of, if you want larger integer values (< 2^53 - 1 and > -2^53 + 1).
Number() also converts to NaN if it's not a number though I would still avoid the + operator here because it is code smell (looks like you forgot your variable to concat).
Number automatically accepts exponent notation and auto-converts to hex (ignoring octal). parseInt() auto-converts hex and octal unless a radix is specified, but it also ignores the remaining non-number characters at the end of the string.
There isn't a single method that does whatever you want.
the String function is also a nice way to cast a value to a string (using .toString() is unsafe because it may not exist, such as with undefined and null): String(42) === "42".
An other thing that could maybe be covered is this specifity:
Since calling constructor functions without `new` is generally an error
The behavior of Number, Boolean, String, and Array is well-defined, it's safe to call them without new. In fact, in the case of String/Boolean/Number, calling them with new will often do something you don't expect. (Calling them with new gives you a Number/String/Boolean object, not primitive, which can cause trouble when you try to compare them with ===, unless you remember to use their `valueOf` method)
Also, as noted below, it's possible for objects to not have a `toString` method, so attempting to call it to get the object's value as a string could blow up. So it's actually safer to coerce to string by adding an empty string or passing to String().
The behavior of Number, Boolean, String, and Array is well-defined, it's safe to call them without new.
ES6 is packed with weird but well-defined things.
The problem is that calling a constructor function (a PascalCase'd function) without `new` looks like an error because it generally is an error. To make matters worse, without closely examining that function, you cannot tell if it's an error.
I do know that `Number()` happens to be one of those constructor functions which not only work without `new`, it also happens to behave differently when `new` is missing. It does not return an object. It returns a primitive.
Someone who doesn't know about this unusual secondary function will waste some time if they spot this apparent mistake.
Now, to defuse this time-wasting trap, you could either add a comment... or just do the sensible thing and write it in a way which does not require a comment.
Comments
Being a bit pedantic here, why not recommending the Number function which may be less obscure for beginners?
If you use a double NOT ~~"foo" you will always get a finite int32 value... which is useful when you can use 0 as a "default" representation. For that matter, all bitwise operations will coerce a value to an int32 representation. Which is something to be aware of, if you want larger integer values (< 2^53 - 1 and > -2^53 + 1).
Number() also converts to NaN if it's not a number though I would still avoid the + operator here because it is code smell (looks like you forgot your variable to concat).
Number automatically accepts exponent notation and auto-converts to hex (ignoring octal). parseInt() auto-converts hex and octal unless a radix is specified, but it also ignores the remaining non-number characters at the end of the string.
There isn't a single method that does whatever you want.
the String function is also a nice way to cast a value to a string (using .toString() is unsafe because it may not exist, such as with undefined and null): String(42) === "42".
An other thing that could maybe be covered is this specifity:
Native constructors are ... fun beasts, to say the least.Another way to cast to a Number is the bitwise-or operator. It has the useful property of always yielding a number.
Bitwise operations don't produce Numbers (f64), but signed integers (i32).
Well, except for right logical shifts.
It always yields an integer, so it's useful if you know you want an integer.
Correct me if I'm wrong, but I thought that the unary operator and the Number constructor yield equivalent results?
Since calling constructor functions without `new` is generally an error, I'd rather use `parseFloat`.
The behavior of Number, Boolean, String, and Array is well-defined, it's safe to call them without new. In fact, in the case of String/Boolean/Number, calling them with new will often do something you don't expect. (Calling them with new gives you a Number/String/Boolean object, not primitive, which can cause trouble when you try to compare them with ===, unless you remember to use their `valueOf` method)
Also, as noted below, it's possible for objects to not have a `toString` method, so attempting to call it to get the object's value as a string could blow up. So it's actually safer to coerce to string by adding an empty string or passing to String().
ES6 is packed with weird but well-defined things.
The problem is that calling a constructor function (a PascalCase'd function) without `new` looks like an error because it generally is an error. To make matters worse, without closely examining that function, you cannot tell if it's an error.
I do know that `Number()` happens to be one of those constructor functions which not only work without `new`, it also happens to behave differently when `new` is missing. It does not return an object. It returns a primitive.
Someone who doesn't know about this unusual secondary function will waste some time if they spot this apparent mistake.
Now, to defuse this time-wasting trap, you could either add a comment... or just do the sensible thing and write it in a way which does not require a comment.
That's fair, I just find them super useful in various situations, for example filtering over an array with Boolean to remove falsey values.
Yes, that's a good suggestion. Boolean works as well, for coercing to boolean of course.
Because Number(...) uses more bytes on the wire.