This question already has answers here:
Closed 10 years ago.
Why does calling 152..toString(2) return a binary string value of "10011000", when a call to 152.toString(2) throws the following exception?
"SyntaxError: identifier starts immediately after numeric literal"
It seems to me that it's intuitive to want to use the latter call to toString(), as it looks & feels correct. The first example just seems plain odd to me.
Does anyone know why JavaScript was designed to behave like this?
A . after a number might seem ambiguous. Is it a decimal or an object member operator?
However, the interpreter decides that it's a decimal, so you're missing the member operator.
It sees it as this:
(10.)toString(); // invalid syntax
When you include the second ., you have a decimal followed by the member operator.
(10.).toString();
#pedants and downvoters
The . character presents an ambiguity. It can be understood to be the member operator, or a decimal, depending on its placement. If there was no ambiguity, there would be no question to ask.
The specification's interpretation of the . character in that particular position is that it will be a decimal. This is defined by the numeric literal syntax of ECMAScript.
Just because the specification resolves the ambiguity for the JS interpreter, doesn't mean that the ambiguity of the . character doesn't exist at all.
The lexer (aka "tokenizer") when reading a new token, and upon first finding a digit, will keep consuming characters (i.e. digits or one dot) until it sees a character that is not part of a legal number.
<152.> is a legal token (the trailing 0 isn't required) but <152..> isn't, so your first example reduces to this series of tokens:
<152.> <.> <toString> <(> <2> <)>
which is the legal (and expected) sequence, whereas the second looks like
<152.> <toString> <(> <2> <)>
which is illegal - there's no period token separating the Number from the toString call.
10. is a float number an you can use toString on float
eg.
parseFloat("10").toString() // "10"
Related
The following code throws an error in javascript:
console.log(String(+0n))
But this code runs successfully:
console.log(String(-0n))
Why +0n throws an error but -0n does not?
So that it doesn't break asm.js:
Unary + followed by an expression is always either a Number, or results in throwing. For this reason, unfortunately, + on a BigInt
needs to throw, rather than being symmetrical with + on Number:
Otherwise, previously "type-declared" asm.js code would now be
polymorphic.
As Bergi highlights in the comments, this was the least bad of three options:
+BigInt -> BigInt: breaks asm.js, and anything else that made the assumption "unary plus gives a Number";
+BigInt -> Number: conflicts with the design decision to disallow implicit conversions between Number and BigInt; or
+BigInt -> error.
+0n is treated as +(BigInt(0)), since unary + means "cast to integer", and it can't automatically do that (for some reason)
console.log(+(BigInt(0)));
-0n is treated as BigInt(-0), since negative numbers can be big integers
(You need to check your console for this, since I guess there's a bug in the StackSnippets preventing BigInts from being casted to a string in the console.log call)
console.log(BigInt(-0));
If I try to write
3.toFixed(5)
there is a syntax error. Using double dots, putting in a space, putting the three in parentheses or using bracket notation allows it to work properly.
3..toFixed(5)
3 .toFixed(5)
(3).toFixed(5)
3["toFixed"](5)
Why doesn't the single dot notation work and which one of these alternatives should I use instead?
The period is part of the number, so the code will be interpreted the same as:
(3.)toFixed(5)
This will naturally give a syntax error, as you can't immediately follow the number with an identifier.
Any method that keeps the period from being interpreted as part of the number would work. I think that the clearest way is to put parentheses around the number:
(3).toFixed(5)
You can't access it because of a flaw in JavaScript's tokenizer. Javascript tries to parse the dot notation on a number as a floating point literal, so you can't follow it with a property or method:
2.toString(); // raises SyntaxError
As you mentioned, there are a couple of workarounds which can be used in order make number literals act as objects too. Any of these is equally valid.
2..toString(); // the second point is correctly recognized
2 .toString(); // note the space left to the dot
(2).toString(); // 2 is evaluated first
To understand more behind object usage and properties, check out the Javascript Garden.
It doesn't work because JavaScript interprets the 3. as being either the start of a floating-point constant (such as 3.5) or else an entire floating-point constant (with 3. == 3.0), so you can't follow it by an identifier (in your case, a property-name). It fails to recognize that you intended the 3 and the . to be two separate tokens.
Any of your workarounds looks fine to me.
This is an ambiguity in the Javascript grammar. When the parser has got some digits and then encounters a dot, it has a choice between "NumberLiteral" (like 3.5) or "MemberExpression" (like 3.foo). I guess this ambiguity cannot be resolved by lookahead because of scientific notation - should 3.e2 be interpreted as 300 or a property e2 of 3? Therefore they voluntary decided to prefer NumberLiterals here, just because there's actually not very much demand for things like 3.foo.
As others have mentioned, Javascript parser interprets the dot after Integer literals as a decimal point and hence it won't invoke the methods or properties on Number object.
To explicitly inform JS parser to invoke the properties or methods on Integer literals, you can use any of the below options:
Two Dot Notation
3..toFixed()
Separating with a space
3 .toFixed()
Write integer as a decimal
3.0.toFixed()
Enclose in parentheses
(3).toFixed()
Assign to a constant or variable
const nbr = 3;
nbr.toFixed()
When I query localStorage.feature7f1c3c10-048d-4ced-8ab8-b88ac91b59ee in an inspector console I receive the below.
SyntaxError: At least one digit must occur after a decimal point
line: 515
message: "At least one digit must occur after a decimal point"
stack: "eval#[native code]↵evaluate#[native code]↵_evaluateOn↵_evaluateAndWrap↵evaluate"
Simple question is why?
The '-' is illegal in keys in dot notation. You will see that
localStorage['feature7f1c3c10-048d-4ced-8ab8-b88ac91b59ee']
is valid.
More on valid JS identifiers (that can be used as keys without quotes) here.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Why can't I access a property of an integer with a single dot?
I was reading an article, and came across the strange behaviour of javascript toFixed method. I don't understand the reason for the last statement. Can anyone explain please?
(42).toFixed(2); // "42.00" Okay
42.toFixed(2); // SyntaxError: identifier starts immediately after numeric literal
42..toFixed(2); // "42.00" This really seems strange
A number in JavaScript is basically this in regex:
[+-]?[0-9]*(?:\.[0-9]*)?(?:[eE][+-]?[0-9]+)?
Note that the quantifiers are greedy. This means when it sees:
42.toFixed(2);
It reads the 42. as the number and then is immediately confronted with toFixed and doesn't know what to do with it.
In the case of 42..toFixed(2), the number is 42. but not 42.. because the regex only allows one dot. Then it sees the . which can only be a call to a member, which is toFixed. Everything works fine.
As far as readability goes, (42).toFixed(2) is far clearer as to its intention.
The dot is ambiguous: decimal point or call member operator. Therefore the error.
42..toFixed(2); is equivalent to (42.).toFixed(2)
js> (5).toString(2)
101
js> 5.toString(2)
js: "<stdin>", line 53: missing ; before statement
js: 5.toString(2)
js: ..........^
js>
Javascript assumes (bizarrely) that a number followed by a dot means the dot is a decimal point. This is counter-intuitive, but at least it's reliable.
You have several choices as to how you deal with this:
(5).toString(2); #1
5..toString(2); #2
5.0.toString(2); #3
5 .toString(2); #4
Stackoverflow's syntax highlighter shows you that, in #2 and #3, the first dot is considered to be part of the number and the second to be the operator. In #4, we can see that the space tells the parser that the number has ended.
Because without the parentheses, the dot in 5.toString() is interpreted as a decimal point. Without parentheses, the interpreter interprets that sequence of characters as a floating point literal.
In Javascript, numbers may be floating point, so 5.0 is a valid number. When you use 5.toString, it looks like toString is the fractional part of the number. Javascript's parser does not handle this case.
Some other languages (such as Ruby) handle this differently.
The interpreter tries to parse the . as a decimal point first, thus it expects toString to be a numeral. Note that the following works since it already has received the decimal:
js> 5.0.toString(2); // -> "101"