The problem isn't limited to the internal [[Delete]] method. The real constraint is that the spec should say (or clearly imply) that Non-configurable properties MUST not disappear.
Excerpted from https://mail.mozilla.org/pipermail/es5-discuss/2011-July/004003.html
On Sun, Jun 19, 2011 at 4:36 AM, David Bruant <david.bruant@labri.fr> wrote:
[...]
ES5.1 11.4.1 the delete operator "In addition, if a delete operator occurs within strict mode code and the property to be deleted has the attribute { [[Configurable]]: false }, a TypeError exception is thrown."
An exception is thrown, however, nothing is said on the destiny of the property. Has it been deleted anyways? One can assume not, but the spec leaves it implicit.
On Jun 28, 2011, at 9:59 AM, Mark S. Miller wrote:
[...]
If the spec nowhere states this explicitly, I would consider it a spec bug to be added to the errata. The intent is clearly that the property not disappear in this circumstance.
On Fri, Jul 1, 2011 at 7:01 AM, Allen Wirfs-Brock <allen@wirfs-brock.com> wrote:
[...]
If it was desired to forbid the implementation of a version of [[Delete]] that ignores the configurable attribute then that restriction should have been stated in section 8.6.2. It isn't there and I don't specifically recall it ever being discussed. Because of this I see this more as a change request then a bug that should be listed in the errata.
If you think such a restriction should be placed on all implementations of [[Delete]] then I suggest that you file a "normative change from ES5.x" bug against the next edition [...]
8.12.7 seems complete and unambiguous:
8.12.7 [[Delete]] (P, Throw)
When the [[Delete]] internal method of O is called with property name P and the Boolean flag Throw, the following steps are taken:
1. Let desc be the result of calling the [[GetOwnProperty]] internal method of O with property name P.
2. If desc is undefined, then return true.
3. If desc.[[Configurable]] is true, then
a. Remove the own property with name P from O.
b. Return true.
4. Else if Throw, then throw a TypeError exception.
5. Return false
To back it up in general, ES5.1 5.2 last paragraph says:
> If an algorithm is defined to “throw an exception”, execution of the algorithmis terminated and no result is returned. The calling algorithms are also terminated, until an algorithm step is reached that explicitly deals with the exception, using terminology such as “If an exception was thrown…”. Once such an algorithm step has been encountered the exception is no longer considered to have occurred.
Allen's point about a for-all-[[Delete]]-implementations restriction requiring new normative spec language seems on target.
/be
Fixed in rev34 editor's draft
added a paragraph to 6.1.7.3 covering this:
An implementation must not allow these invariants to be circumvented in any manner such as by providing alternative interfaces that implement the functionality of the essential internal methods without enforcing their invariants.
fixed in rev34