> generics are better in Swift (and for example C#) because of that
Disagree. Reified generics let you write functions that do different things based on the runtime type of an object, but such functions are confusing to a reader and best avoided.
> Swift has associated values with enums
Java/Kotlin style enums are my favourite from any language, since they're first-class objects; you can give them a value in a field if that's what you want, but you can also have them implement an interface etc.
> ARC is simpler to predict but can induce a performance penalty.
In the general case ARC has the same pause problems as traditional GC, since you can't tell when one reference is the last living reference to an arbitrarily large object graph.
> Swift is a bit more secure in terms of "it compiles, it works" than Kotlin
How so? If anything I'd have expected the opposite.
Fair enough. Looking into it, swift's "associated values" sound super weird; it seems like it means you can have multiple distinct instances for the same enum case, which breaks what I'd expect an enum to be. In fact an enum with associated values sounds more like a sealed class - both those concepts exist in Kotlin, but they're different and the difference is useful.
Like I said, you can write the same kind of thing very easily in Kotlin by using a sealed class - your example would translate line-for-line. It's a useful feature. But it's very confusing to call it a kind of enum rather than as a kind of class; as your other post acknowledges, it means Swift essentially has two different things that are differently implemented but both called "enum".
Disagree. Reified generics let you write functions that do different things based on the runtime type of an object, but such functions are confusing to a reader and best avoided.
> Swift has associated values with enums
Java/Kotlin style enums are my favourite from any language, since they're first-class objects; you can give them a value in a field if that's what you want, but you can also have them implement an interface etc.
> ARC is simpler to predict but can induce a performance penalty.
In the general case ARC has the same pause problems as traditional GC, since you can't tell when one reference is the last living reference to an arbitrarily large object graph.
> Swift is a bit more secure in terms of "it compiles, it works" than Kotlin
How so? If anything I'd have expected the opposite.