559335 - Behavior of delete v[i] on Vector v is undocumented (actually unspecified!)

Status: RESOLVED WONTFIX

(Tamarin Graveyard :: Virtual Machine, defect, P3)

Description

[Felix S. Klock II [:pnkfelix, :fklock]]

It looks like delete v[i] is practically a no-op.  I found this a bit unintuitive (we support splice but not delete?)  I can understand not supporting delete v[i] for type-specialized vectors since they presumably cannot support having the undefined value as an entry, but in that case I would have expected an Exception in response to delete, not a silent no-op.

(The reason this is weird to me is that it breaks a hypothetical invariant that "delete v[i]; return (i in v)" would always return false.)

I looked at the official Vector docs http://help.adobe.com/en_US/AS3LCR/Flash_10.0/Vector.html
and at the speclet http://asteam.macromedia.com/hg/specs/file/tip/speclets/Vector.html
but found no discussion of how delete works with Vector.

(am attaching file I used to investigate behavior of Vector in comparison with Array...)

Comment 1

[Felix S. Klock II [:pnkfelix, :fklock]]

Attachment: investigation of delete on vector

Comment 2

[Felix S. Klock II [:pnkfelix, :fklock]]

Seems like ByteArray documentation suffers from the same problem, but I have not investigated thoroughly.

Comment 3

[djacowit]

Since Vectors behave like arrays, I think this page has the information:
http://help.adobe.com/en_US/as3/dev/WS5b3ccc516d4fbf351e63e3d118a9b90204-7ee5.html#WSB1F41227-C612-4f33-A00E-CE84C1913E1C

It's definitely odd:
"You may come across code that uses the delete operator on an Array object element. The delete operator sets the value of an Array element to undefined, but it does not remove the element from the Array."

and then goes on to say you can then truncate the array. So, it seems like the best option we have is 1) remove the element, 2) truncate the array.

Comment 4

[djacowit]

or use splice(). I'm starting to think this is as designed. If you're referencing elements in an array and one of them is removed, you don't necessarily want the positions of all the other elements to change.

Comment 5

[Felix S. Klock II [:pnkfelix, :fklock]]

(In reply to comment #3)
> Since Vectors behave like arrays, I think this page has the information:
> http://help.adobe.com/en_US/as3/dev/WS5b3ccc516d4fbf351e63e3d118a9b90204-7ee5.html#WSB1F41227-C612-4f33-A00E-CE84C1913E1C
> 
> It's definitely odd:
> "You may come across code that uses the delete operator on an Array object
> element. The delete operator sets the value of an Array element to undefined,
> but it does not remove the element from the Array."

Using delete on an element of an Array object sets that element to undefined.

But some variants Vector (as well as ByteArray) do not have the option of representing an undefined element.  For example a vector<int> always holds ints.  That's why the illustrative code in attachment 438988 [details] ends with testing delete on a vector<int>.

Therefore it is not sufficient to point a developer to the above Array documentation; Vector *has* to be an exception to that rule.

Comment 6

[Lars T Hansen]

(In reply to comment #5)
> 
> Using delete on an element of an Array object sets that element to undefined.

It most emphatically does not.  'delete' removes the element from the Array's set of "indexed" (named by uint32) properties but otherwise leaves the array unchanged.  If you subsequently read that element you will normally observe an "undefined" value, but the in operator, for-in enumeration, and prototype chain lookups can reveal that the element does not exist in the array - though it may exist in a prototype object.

Thus, "delete v[i]; return i in v;" is not guaranteed to return false, since i may exist in a prototype object of v, ie, it's not an invariant for Arrays.

If the docs say what the quote in comment #3 says they say, then the docs need to be fixed - that language is just plain wrong.

Since a Vector can't have a hole delete v[i] doesn't make a lot of sense.  Intuitively if T is a type and v is Vector.<T> then I would expect delete v[i] to have roughly the effect of

  v[i] = D

where D is a suitable default value for T (typically null or 0) or undefined or undefined cast to T, depending on temperament...

(Will follow up with more when I've researched the ES4 working notes some, and tested a little.)

Comment 7

[Lars T Hansen]

So far as I can tell the ES4 documents (as of Spring 2008), source code, proposals, and bugs do not contain any information about the delete operator's behavior on vectors.

The library spec says nothing, it just includes the reference implementation's signature - so presumably that part was never written.  (I checked the source, not just the PDF.)

The original vector proposal, http://wiki.ecmascript.org/doku.php?id=proposals:vector, is silent on the issue.

There is only a stubbed-out definition of the delete operator in the sources:

        /* Not possible in current refimpl
        meta final function delete(name) {
            // To be written
        }
        */

(The reason it's "not possible" is because the parser couldn't handle "delete", which is a keyword - ie nothing fundamental.)

I can't find anything in the bugbase on http://bugs.ecmascript.org, which tracked ES4 bugs, about the behavior of the delete operator on Vector instances.

-----

It appears that the vector implementation in tamarin has no code for the delete operator at all; the behavior of delete is a consequence of vector properties not being handled like normal dynamic properties but like internal properties.

-----

On the one hand, as the behavior of delete[i] is a no-op (unclear to me what "practically a no-op" in the original report means) and it would require versioning to fix that and the fixed behavior wouldn't be terribly useful it may be sufficient to document (and ensure) that it /is/ a no-op.

On the other hand, arguments in favor of making it not a no-op but giving it the semantics of assigning a default value are (a) that we'd get range checking as expected and (b) that developer brain print about using 'delete a[i]' to clear out array properties to allow GC to work would work also on vectors and (c) that 'delete v[i]' would assign an appropriate null value for the base type of v so that the developer would not have to worry about null vs 0 vs undefined.

cc'ing more brains.

Comment 8

[Lars T Hansen]

This is not simply a doc bug, but a VM behavior issue, a Vector spec issue, and then finally a documentation issue.

Comment 9

[Sylvestre Ledru [:Sylvestre]]

Tamarin is a dead project now. Mass WONTFIX.

Comment 10

[Sylvestre Ledru [:Sylvestre]]

Tamarin isn't maintained anymore. WONTFIX remaining bugs.