> On Jan 2, 2017, at 1:52 AM, Georgios Moschovitis
> wrote:
>
> Btw, isn’t it strange that the next() method in `IteratorProtocol` *is*
> mutating, and makeIterator() is not?
Iterators are inherently stateful things. But for collections, the state they
are mutating is their own progress thro
> But if you do this you will get a different compiler error, because your
> struct will no longer conform to Sequence, which requires makeIterator to be
> non-mutating. This is important, especially assuming your array is eventually
> going to conform to Collection as well. One of the requireme
Hey Ben,
Thank you for taking the time to provide this detailed explanation.
Very helpful indeed.
George.
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users
Nice catch. Here’s a minimal test case:
struct G {}
func f1(_: inout G) {}
func f2(_: inout G) {}
func g1(t: G) {
let _ = f1(&t) // cannot pass immutable value as inout argument: 't' is a
'let' constant
}
func g2(t: G) {
let _ = f2(&t) // cannot convert value of type 'G' to expected argume
Hi Georgios,
Yes, that isn’t the best of error messages.
The problem is that makeIterator() is not a mutating function, so inside it all
properties are treated as immutable. This means you aren’t allowed to pass them
into functions as inout arguments. It’s essentially the same as this:
func ta
> On Jan 1, 2017, at 10:48, Georgios Moschovitis via swift-users
> wrote:
>
> While getting my feet wet with Swift, I am still surprised with type-system
> ‘quirks’ here and there.
>
> I tried to implement a simple array of weak references:
>
> public struct WeakArrayIterator: IteratorProtoc
While getting my feet wet with Swift, I am still surprised with type-system
‘quirks’ here and there.
I tried to implement a simple array of weak references:
public struct WeakArrayIterator: IteratorProtocol {
var array: [Weak]
var index = 0
init(_ array: [Weak]) {
self.a
