An array destructing specification choice

Allen Wirfs-Brock allen at
Sun Nov 6 11:18:39 PST 2011

On Nov 6, 2011, at 3:53 AM, Till Schneidereit wrote:
>> ...
> After thinking about this some more, I think I'd be fine with the
> above outcome after all. It seems to me as though the array
> destructuring pattern really only uses the syntax of arrays, not
> necessarily their semantics. Once row capture comes into play, not
> even the syntax matches completely, anymore.

I'm skeptical of ES every supporting row capture.  It is essentially an shallow copy (with exclusions) operation and it brings into to play all the copy semantics issues that up to this point we have been unwilling to try to take on.

> The important difference is that, as opposed to the slice example
> above, at no point during array destructuring an array object is
> created or modified.

Well, a (real) array object is created is a rest pattern is used.

> Given that, isn't the array destructuring pattern
> really a convenient way of saying "in this destructuring, all keys are
> numeric indices, starting at 0 and increasing linearly by 1"? I.e.,
> it's mostly syntax for another form of shorthand, pretty similar to
> {x} = {x:1}.

or does the use of the [ ] pattern also imply some deeper user intent about applying array-like semantics. 

> Assuming that, I don't see why length should be used, anymore.
> I'm still with Allen on one point: Length should either not be used at
> all, or in all array destructuring operations. The alternative would
> turn refactoring to ... into a potentially surprising operation for
> destructuring, compared to its other uses. Consider
> [a, b, c] = {length:0, 0:0, 1:1, 2:2}
> //results in a = 0, b = 1, c = 2
> Now if that's refactored to
> [a, ...r]
> if length is used, the result is
> a = 0, r = []
> if length isn't used, the result is
> a = 0, r = [1, 2]
> The latter is exactly the behavior of using ... in function signatures
> - and, I posit, much less surprising in itself.

I'm not sure the comparison to function parameters is valid for this case. A function parameter list can be modeled as a destructuring over the "arguments object"  (that's actually how I'm in the process of specifying it) and for extended code (the only code that can use rest parameters) the "arguments object" is a real array with a valid "length" property. The RHS in your above example, is not a well formed array and could never appear as such an arguments object.  

> I can't say anything about implementation hardships, but from a
> usability point of view, I'd say the usage of length should be [no,
> no] or [yes, yes], with a strong preference for the former.

I do have concerns about the implementation implications of [no,no]

For [yes, yes]  ... can be implemented as an iteration from the last accessed index position up to the value of the "length" property, checking for the existence of each index property key.   For most non-array objects on the RHS, there won't be a "length" property so its integer value is consider to be 0 and no iteration occurs. 

For [no, no] to implement ... we have to assume that the iteration limit is the max possible array index (currently Uint32 max - 1, but we are considering relaxing the Uint32 restriction on arrays).  Since such an iteration bound is impractical, what implementations will instead have to do  is inspect every property (including inherited properties with proper application of shadowing rules) of the RHS object to determine whether they are "array index" properties whose keys are greater than the last accessed index. Note that this even has to be done for "real" array objects because they can have inherited integer keyed properties whose value is greater than the "length" value of he array.  Since this is a property inspection, not a integer ranged loop, we will  ultimately have to sort the identified properties into index order before populating the result array.

Note that in most cases there will be no such integer keyed properties to gather but we still have to inspect every property to see if it is one.  So, we have turned destructuring ... into a potentially quite expensive operation, even for simple cases. Perhaps implementations can apply some of their already implemented "array" indexed property optimizations to limit the search space but I still think that we should think about such implementation considerations as we make these semantic decisions.


> till

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

More information about the es-discuss mailing list