This was discovered by jrgm. Here is a session in the JS shell: ./js -w js> const one=1; js> const one=2; 4: TypeError: redeclaration of const one js> one=2; 2 This shows that we get a warning if we try to redeclare a const, but we do not get a warning if we try to reassign to a const. It's true, the new value doesn't take: js> one 1 but there should be a warning, no?
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.8
Oh, wow. That's not good. 0.9.8 is coming up fast, any indications of work on this?
cc'ing Brendan in case this is of interest -
That's per ECMA (don't blame me, I fought for what Netscape always did: throw an error [could be a catchable exception since 1.3]). Readonly properties, when set by assignment, are not changed, but no error or exception is thrown. The value of the assignment expression is the value of the r.h.s. If you want a *strict* warning, please change the summary of this bug to say so. /be
Yeah, I only meant strict. I'm not particularly worried about whether/when this gets done. I just noticed that there was no warning for this, and it seems like something a strict mode should flag.
Summary: Not getting a JS warning if I try to reassign to a const → Not getting a JS strict warning if I try to reassign to a const
Summary: Not getting a JS strict warning if I try to reassign to a const → Not getting a JS strict warning for reassigning to a const
Same behavior occurring with the -s option as with the -w option above: ./js -s js> const one=1; js> one=2; 2 js> one 1 but no warning is given -
Testcase added to JS testsuite to ensure what Brendan described in Comment #4: mozilla/js/tests/js1_5/Regress/regress-103602.js
shaver reminded me that exceptions didn't show up until js1.4. This is a low priority bug, are we sure it should be targeted at 0.9.8? /be
Target Milestone: mozilla0.9.8 → Future
Assignee: khanson → general
Status: ASSIGNED → NEW
QA Contact: pschwartau → general
Target Milestone: Future → ---
Tested this out just now, I think it is fixed: js> const one = 1 js> one = 2 typein:2: strict warning: one is read-only 2
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED
verified on 1.8, 1.9 windows.
Status: RESOLVED → VERIFIED
Tradition would mark this bug WFM unless we know the bug that was patched to fix this symptom. A little cvs annotate -r and cvs diff archeology discloses: revision 3.230 date: 2005/12/01 21:05:12; author: brendan%mozilla.org; state: Exp; lines: +24 -24 Followup to maximize error-reporting code sharing (315436, r=daumling). ---------------------------- revision 3.229 date: 2005/12/01 02:26:35; author: brendan%mozilla.org; state: Exp; lines: +25 -7 Fix from Michael Daumling <email@example.com> to make read-only assignment a strict warning (315436, r/sr=mrbkap/brendan). This is when the fix went in. /be
Assignment is not declaration. The redeclaration warning is only when const is used to declare the constant identifier. I don't think this regressed: $ ./Darwin_DBG.OBJ/js -sw js> const one=1 js> one=2 typein:2: strict warning: one is read-only 2 Are you (is Will, I mean) sure you have strict warnings turned on? /be
My bad, there is no regression. Two factors confused me: The reassignment warnings go straight to the JS Console, they are not exceptions which can be caught and displayed by the JS Shell extension. I was using an old build with bug 324142, so nothing appeared in the JS Console
You need to log in before you can comment on or make changes to this bug.