Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Enumerations can satisfy protocol requirements in Swift; they're first class.


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.


Associated values in enums make sense, if you look at the enum as a class/struct, under the hood.

It's quite powerful, once you get your head around it.

I write about that here: https://littlegreenviper.com/miscellany/swiftwater/enums-wit...

And here: https://littlegreenviper.com/miscellany/swiftwater/writing-a...


> Associated values in enums make sense, if you look at the enum as a class/struct, under the hood.

But they don't make sense as enums. If you have to look "under the hood" to get a reasonable model of a feature, it's a bad design.

> It's quite powerful, once you get your head around it.

> I write about that here: https://littlegreenviper.com/miscellany/swiftwater/enums-wit....

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".


Yes. The enum behaves quite differently, depending on whether or not it has associated values.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: