On behalf of Dmitri Gribenko, Max Moiseev, and myself:
on Thu May 19 2016, Kevin Ballard
wrote:
> After having given this some thought, it seems apparent that `sequence
> (state:next:)` is equivalent to `AnyIterator({ ... })` where the closure
> captures a single mutable variable.
Yes.
on Wed May 25 2016, Erica Sadun wrote:
> On May 25, 2016, at 2:18 PM, Kevin Ballard via swift-evolution
> wrote:
>
> We think the need to do a capture is icky, so the sequence form is
> almost always better.
>
> I agree that the need for a capture is ugly.
>
> The design of AnySequence an
> On May 25, 2016, at 2:18 PM, Kevin Ballard via swift-evolution
> wrote:
>> We think the need to do a capture is icky, so the sequence form is
>> almost always better.
>
> I agree that the need for a capture is ugly.
>> The design of AnySequence and AnyIterator dates from a time when the
>> c
On Wed, May 25, 2016, at 01:08 PM, Dave Abrahams wrote:
>
>
>
> On behalf of Dmitri Gribenko, Max Moiseev, and myself:
>
> on Thu May 19 2016, Kevin Ballard
> wrote:
>
> > After having given this some thought, it seems apparent that `sequence
> > (state:next:)` is equivalent to `AnyIterator(
On Mon, May 23, 2016, at 05:44 AM, Jeremy Pereira via swift-evolution wrote:
>
> > On 19 May 2016, at 23:29, Chris Lattner via swift-evolution
> > wrote:
> >
> >
> > * What is your evaluation of the proposal?
>
> +1
>
> I think I would find myself using this in loads of places, if it was
> On 19 May 2016, at 23:29, Chris Lattner via swift-evolution
> wrote:
>
>
> * What is your evaluation of the proposal?
+1
I think I would find myself using this in loads of places, if it was
implemented.
One question: what is the downside of making these functions `rethrows` and
al
* What is your evaluation of the proposal?
+1. These are useful additions to the standard library.
Naming the first argument `initial` (in the `T->T?` variant) is consistent with
`reduce` and makes it clear (to me) that the initial value is part of the
result.
* Is the problem
On Thu, May 19, 2016, at 05:59 PM, Patrick Smith wrote:
> This sounds fair to me. I imagine a functional version would return
> two item tuple instead of mutating, so would it be that similar to
> what people expect?
A functional version of `sequence(state:next:)` would indeed use the
type signat
>
> * What is your evaluation of the proposal?
+1. These functions are really handy. The standard library should definitely
include commonly useful utilities like these.
> * Is the problem being addressed significant enough to warrant a
> change to Swift?
Yes. It’s best to
Once you start using it, it's really hard to put it down.
-- E, who will not make the obvious "for" joke
> On May 19, 2016, at 7:10 PM, Patrick Smith wrote:
>
> I think that is a little confusing and has potential to be ‘abused’. I think
> it’s more confusing that a `for(;;)` loop for instanc
I think that is a little confusing and has potential to be ‘abused’. I think
it’s more confusing that a `for(;;)` loop for instance, and that got removed. I
think var + AnyIterator is more explicit, and can become the canonical way to
do this.
Hopefully AnyIterator can be optimized to the same
This sounds fair to me. I imagine a functional version would return two item
tuple instead of mutating, so would it be that similar to what people expect?
> On 20 May 2016, at 10:52 AM, Kevin Ballard via swift-evolution
> wrote:
>
> After having given this some thought, it seems apparent that
> On May 19, 2016, at 6:52 PM, Kevin Ballard via swift-evolution
> wrote:
>
> After having given this some thought, it seems apparent that
> `sequence(state:next:)` is equivalent to `AnyIterator({ ... })` where the
> closure captures a single mutable variable. The microbenchmark performance
After having given this some thought, it seems apparent that
`sequence(state:next:)` is equivalent to `AnyIterator({ ... })` where
the closure captures a single mutable variable. The microbenchmark
performance may differ slightly, as the AnyIterator version will
allocate a box on the heap to hold
It would certainly be clearer that the state is changing on each
"iteration", but I'm not sure it's worth such a long parameter label. Maybe
`sequence(state:update:)`?
On Thu, May 19, 2016 at 8:46 PM, Patrick Smith wrote:
> Would `sequence(mutatingState:next:)` perhaps be clearer?
>
>
> On 20 Ma
Would `sequence(mutatingState:next:)` perhaps be clearer?
> On 20 May 2016, at 10:37 AM, Trent Nadeau via swift-evolution
> wrote:
>
> Ah, yes. I apologize. The fact that state is inout, and the same instance is
> always passed in confused me. Thanks for the correction.
>
> On Thu, May 19, 2
Ah, yes. I apologize. The fact that state is inout, and the same instance
is always passed in confused me. Thanks for the correction.
On Thu, May 19, 2016 at 7:46 PM, Brent Royal-Gordon
wrote:
> > Also note that there's a typo in the second example:
> >
> > for view in sequence(initial: someView
> Also note that there's a typo in the second example:
>
> for view in sequence(initial: someView, next: { $0.
> superview }) {
>
> // someView, someView.superview, someView.superview.superview, ...
>
> }
>
>
> should be:
>
> for view in sequence(state: someView, next: { $0.
> superview }
On Thu, May 19, 2016, at 04:20 PM, Trent Nadeau via swift-evolution wrote:
> Also note that there's a typo in the second example:
>
> for view in sequence(initial: someView, next: { $.superview }) { //
> someView, someView.superview, someView.superview.superview, ... }
>
> should be:
>
> for view
* What is your evaluation of the proposal?
+1. I've used unfold/iterate functions in Haskell and Clojure, and they are
very useful.
* Is the problem being addressed significant enough to warrant a
change to Swift?
Yes.
* Does this proposal fit well with the feel and directio
Hello Swift community,
The review of "SE-0094: Add sequence(initial:next:) and sequence(state:next:)
to the stdlib" begins now and runs through May 23. This is a refinement of part
of SE-0045. The proposal is available here:
https://github.com/apple/swift-evolution/blob/master/proposa
21 matches
Mail list logo
