'void' as a value

Andrew Fedoniouk news at terrainformatica.com
Sun Sep 8 14:11:25 PDT 2013

On Sun, Sep 8, 2013 at 12:39 PM, Brendan Eich <brendan at mozilla.com> wrote:
> Lately people post overlong proposals that do not define the proposed
> primitives first. Also errors in the sketching don't help credibility.
>> Andrew Fedoniouk <mailto:news at terrainformatica.com>
>> September 8, 2013 11:24 AM
>> Consider this Range implementation:
>> function Range(low, high){
>> var index = low;
>> return function() { if( index < high ) return index++; }
>> }
>> and its use:
>> for(var i in Range(0,10) )
> You must mean for (var i of Range(0, 10)) here, because for-in cannot be
> changed to iterate without breaking backward compatibility.

Correct, "for..of"  is the right construct for that.

>> ...
>> Internal implementation of for..in is calling the function in each
>> iteration
>> and stops when the function will return 'void'.
> Assuming you mean for-of, the problems for any "new undefined-like sentinel"
> remain:
> * It will be too easily returned by accident, especially given how it is
> hard to distinguish from undefined.

I do not understand the problem to be honest. Are you saying that
it is hard to distinguish these two cases:

  return something;
  // and


> * It may end up in collections being iterated over, causing premature
> termination.

I think you've missed my point. 'void' IS 'undefined' by any means
except of slightly
different internal representation. It is like 'undefined' value has
special flag .isVoid that
is not exposed outside.

While assigning that undefined/isVoid value to any variable or field
the isVoid gets
cleared - in other words you cannot store void value anywhere.

So collections or variables simply cannot contain 'void' values. void is void.

> Any in-band value is a problem by the latter point. Thus the previous
> Pythonic out-of-band StopIteration exception, or the current ES6 wrapping of
> iteration protocol step results in {value, done} structure to avoid
> overloading the returned value and creating a pigeon hole problem.

{value, done}  creates another problem - heap pollution, this:

var counter = 0;
for( var n of Range(0,10) )

should not cause heap allocations. In case of protocol you've described
{value, done} object gets allocated. And I suspect it is so on each iteration.



Creo en tu palabra.

Andrew Fedoniouk.


More information about the es-discuss mailing list