Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

how do people deal with iterating a Swift struct value-type property?

Here's an obvious situation that must arise all the time for people:

struct Foundation {
    var columns : [Column] = [Column(), Column()]
}
struct Column : CustomStringConvertible {
    var cards = [Card]()
    var description : String {
        return String(describing:self.cards)
    }
}
struct Card {}
var f = Foundation()
for var c in f.columns {
    c.cards.append(Card())
}

That code is legal but of course it has no effect on f, because var c is still a copy — the actual columns of f are unaffected.

I am not having any difficulties understanding why that happens. My question is what people generally do about it.

Clearly I can just make the whole matter go away by declaring Column a class instead of a struct, but is that what people usually do? (I'm trying to follow a mental stricture that one should avoid classes when there's no need for dynamic dispatch / polymorphism / subclassing; maybe I'm carrying that too far, or maybe there's something else people usually do, like using inout somehow.)

like image 940
matt Avatar asked Jan 02 '19 23:01

matt


1 Answers

As of Swift 4, a compromise is to iterate over the indices of a mutable collection instead of the elements themselves, so that

for elem in mutableCollection {
    // `elem` is immutable ...
}

or

for var elem in mutableCollection {
   // `elem` is mutable, but a _copy_ of the collection element ...
}

becomes

for idx in mutableCollection.indices {
    // mutate `mutableCollection[idx]` ...
}

In your example:

for idx in f.columns.indices {
   f.columns[idx].cards.append(Card()) 
}

As @Hamish pointed out in the comments, a future version of Swift may implement a mutating iteration, making

for inout elem in mutableCollection {
   // mutate `elem` ...
}

possible.

like image 158
Martin R Avatar answered Sep 20 '22 19:09

Martin R