Hacker News Reader

Comment by abalone | Hacker News Reader

var wine = Set<String>()

wine.insert("Champagne")

Oof, magic strings. Always use enums!

    enum Booze: String {
        case wine,
        case champagne,
        case beer,
        case whiskey
    }

    let wine = [Booze.champagne]

</ocd>

wine's type should conform to a Stack protocol so you can pop champagne.

I'm not sure if it was intentional but "case beer" made me smile.

Nooooooo... you're right about enums but this codifies the same error I was trying to elucidate with code. Here, let's try this:

   enum Booze {
     case Wine(region: String)
     case Beer
     case Whiskey
   }

   let drink = Booze.Wine(region: "Champagne")

Now.. Anyone want to demonstrate how to use enums for the wine region or, say, whiskey subtypes? Should we use classes?

I feel like adding a pull request to add whisky to the list. Some of us prefer scotch.

Definitely have to +1 this. I'd be happy to write some tests to get scotch on board.

You don't need commas :)

Why are these String, not just enums?

Because it's replacing a Magic String?

So strings are mutable? I'm not sure that's a reason to celebrate.

The example does not demonstrate mutability of strings; it is constructing a set of strings and inserting a string element. Only the set is being mutated.

But yes, in Swift, arrays, dictionaries, sets and strings are all mutable. They are also value types, so mutation is a purely local effect.

I think what the example is supposed to demonstrate is that champagne is a type of wine.

Would that not make passing around data expensive? Or are you expected to pass some kind of pointer instead?

Copy-on-write alleviates some of the overhead. Copies are only performed where required to preserve value semantics.

All of these can be both mutable or immutable. And converted as needed

let array = [1, 2, 3] var mutableArray = [4, 5, 6] var anotherMutable = array

Not sure how much optimisation is done under the hood, but Swift compiler loves to complain about mutable structures that are not ever edited.

These are all copy-on-write boxed types with value semantics: the value you pass around is a pointer (with some additional data) and Swift has mechanisms/API which let the implementor copy the backing buffer on mutation if necessary: https://developer.apple.com/documentation/swift/2429905-iskn...

Strings (and arrays and sets and dictionaries) are neither mutable nor immutable in Swift, they're just values. Mutability is a property of where they're stored, not the types themselves. They work just like numbers do in most programming languages: you wouldn't say that Java's `int` is mutable or immutable, it just is. It may be stored in a mutable or immutable location, but the type itself doesn't have that property.

Reply on news.ycombinator.com