I'm not pointing out an issue in particular, just explaining why Andy
is right with his specific statement about implementations not using
generators (which Dave seemed surprised about, or have misread, I'm
not sure).
(You are right to assume that built-in iterators would not need .return.)
/Andr
I'm not concerned about manually added .return methods, nor manual calls to
.return methods, though perhaps I should be. If this is a concern, we could
solve it by using an @return symbol in ES7 rather than a string name.
Neither am I concerned about system iterators, assuming that none of the
syst
Domenic: the argument against is that changing the semantics of `for of` --
and all of the standard library methods, in the case of exceptional exit --
would result in a user-visible change to the state of the iterator. That
is, the iterator would not be closed, whereas ES6 as it stands now would
Can someone summarize the argument as to why this can't be added later? Is the
fear that people will create iterators with `return` methods and depend on
those methods *not* being called, but then ES7 would start calling them?
___
es-discuss mailing li
On Tue, Apr 29, 2014 at 4:32 AM, Kevin Smith wrote:
> I agree with pretty much everything Andy had to say, and would like to add
> a meta-perspective:
>
> We should be viewing this as a last-minute feature request. The churn
> that this request has introduced is (in my opinion) exactly the kind
I don't think I understand the issue. AFAICT, all the system implemented
iterators don't need to clean up anything that's not already cleaned up by
GC, so they wouldn't need a .return method anyway. Is there a
counter-example?
On Wed, Apr 30, 2014 at 3:48 AM, Andreas Rossberg wrote:
> On 29 Apri
On 29 April 2014 20:35, David Herman wrote:
> On Apr 29, 2014, at 12:40 AM, Andy Wingo wrote:
>> Indeed I expect that in
>> practice most iterators in an ES6 program will be map, set, and array
>> iterators, which in practice will not be implemented with generators.
>
> I strongly disagree with t
Minor correction to Domenic's comments in this (interesting)
discussion; IEnumerable and IDisposable are separate concepts in C#.
Neither IEnumerable or IEnumerator are disposable objects in C#;
*however*, if you use 'for each' on an object that yields an
enumerator that is *also* disposable, the c
On Tue, Apr 29, 2014 at 4:07 PM, Jason Orendorff
wrote:
> On Tue, Apr 29, 2014 at 2:40 AM, Andy Wingo wrote:
> > == Calling return() on early exit from for-of is expensive
> >
> > Wrapping a try/finally around each for-of is going to be really
> > expensive in all engines right now. I'm skeptica
On Apr 29, 2014, at 12:17 PM, Domenic Denicola
wrote:
> Anyway, regardless of the specifics of my `using` proposal, I hope that
> highlighting the iterability vs. disposability aspects of this conversation
> was helpful to people.
I do think it's helpful for understanding the space, thanks.
On Tue, Apr 29, 2014 at 2:40 AM, Andy Wingo wrote:
> == Calling return() on early exit from for-of is expensive
>
> Wrapping a try/finally around each for-of is going to be really
> expensive in all engines right now. I'm skeptical about our ability to
> optimize this one away. Avoiding try/catc
Brendan Eich wrote:
Indeed with rapid release, penalizing convenience and waiting for
ecosystem effects can make overcomplicated, convenient
"inconvenient"
, and just bad total designs out of piecewise steps that you might
like because they avoid committing to convenience :-P.
/be
Domenic Denicola wrote:
Dave and Andy's responses have me pinging back and forth as to which "side" I'm
on.
Are you off the fence yet? I can't tell :-P.
But inconvenience is easily solved via MOAR SUGAR:
```js
for (var line using files) {
if (line == '-- mark --') {
break;
}
}
``
Dave and Andy's responses have me pinging back and forth as to which "side" I'm
on. Both seem convincing. Dave's response especially brought the issue into
focus for me in a way that I think is clear, so let me explain what I learned
from it:
What we are essentially talking about here are two t
I'm sympathetic to the "simplicity" argument that says that `.throw` is the
proper way in JS to clean up an iterator. The `.return` proposal seems
like a kludge to work around the fact that ES6 still doesn't have a
discriminatory `catch` clause that can avoid catching the thrown cleanup
exception.
On Apr 29, 2014, at 12:40 AM, Andy Wingo wrote:
> I'm a bit grumpy that this is being brought up again, and
> this late, and in multiple forums, but as it seems that people want to
> talk about it again, that talking about it again is the thing to do...
Sorry about that. :( But the fact is Jafar
I agree with pretty much everything Andy had to say, and would like to add
a meta-perspective:
We should be viewing this as a last-minute feature request. The churn that
this request has introduced is (in my opinion) exactly the kind of problem
that the ES7 process is meant to address. In fact,
On Fri 25 Apr 2014 16:22, Domenic Denicola writes:
>> (2) not well-motivated according to some participants of the
> discussion (e.g., it's not necessarily a good idea to rely on
> finally-blocks for scarce resource management in the first place, since
> they provide only weak guarantees either w
18 matches
Mail list logo
