ES3.1-strict spec bug & proposed fix: method calls on primitives.

Brendan Eich brendan at
Thu Jan 8 21:30:40 PST 2009

On Jan 8, 2009, at 9:27 PM, Mark S. Miller wrote:

> On Thu, Jan 8, 2009 at 9:14 PM, Brendan Eich <brendan at>  
> wrote:
> [lots of agreement]
> Wonderful!
> Generic programming with primtiives more often wants to *read*  
> undefined when getting a non-existent property, and "object detect"  
> without having to try/catch. This common use case is not served by  
> strict mode in ES3.1, right? You'd have to change code to try/catch  
> around such probes.
> ES3.1-strict and nonstrict both return undefined from a failed read  
> for exactly this reason, as does Caja. The feature testing pattern  
> is pervasive and we dared not break it. The rationale is that a  
> failed read is *not* silent n practice, and so is adequately non- 
> hazardous for integrity. It returns an undefined, which is likely to  
> be noticed, since the operation in question is, after all, a read.

Oh good -- I misremembered.

> This rationale does not apply to "delete" returning false, since in  
> practice much code calls delete, assumes success, and does not check  
> the return value. In the face of new user-defined non-configurable  
> properties, failed deletes will be more common, so this hazard  
> becomes worse. So a failed strict delete does throw. You do indeed  
> have to place try/catches around strict deletes to simulate their  
> current behavior.

It's hard to care, frankly. The Netscape 2 JS1.0 implementation had,  
if memory serves, delete as a statement, not an operator. :-P

The rationale "we dare not break" applies to other cases of making the  
strict mode migration tax too high. This came up in the wiki just now,  
and I've commented in-line at

Spin-off thread fodder, change of subject appropriate if you take my  
bait ;-).


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Es-discuss mailing list