Unpacking New Toys

Working on building a complete simple app in Swift is a very interesting experience. There's a dearth of high quality reference material, no style guides, and the rough edges that are to be expected in beta software are present. That being said, even with those problems I'm enjoying working with it the most out of the four programming languages I'm currently touching on a daily basis.

Type Safety, and Type Inference

Type inference is taking getting used to. As I get more used to doing it in Swift, it feels like an omission in the other languages that I work in. I also feel like it's going to help prevent coding decisions that I'll regret in the future.

Like shove three different classes without a shared protocol or class into and array the data source for a table view. I was not happy with my past self when I cleaned up that class.

Operator Overloading

This is the programing toy box equivalent of "Jarts". It seems really cool, but I know it will end poorly without strict rules and lots of care if I play with it.

Generics

I have high hopes to mix generics and protocols to do a significant amount of what I did shoving more classes than I should into an array, but without the painful unpacking step later.

Optionals

I still find optionals a bit strange. In the Swift data layer code that I'm writing they've been useful for making my code more concise, and make for a good reminder of what

Enumerators

In some of my larger projects I've leaned heavily on enumerators, especially for custom table view data sources. Being able to put more of the values in that enumerator rather than in functions in the class using the enumerator will hopefully require less code and make for a nicer structure to the code.

Tuples

It's going to take a while for me to get used to tuples, but long term they seem like a great way to deal with errors, and just a great away to pass around mixed data types without having to create a struct or class to contain the variables.

Structs

It's going to take me a little while to get used to when to use a struct to contain data rather than a class, but I think once I develop real standards on that it should be another useful level of separation between data and control code.

Closures

Which I keep wanting to call "blocks." I was using blocks a lot in my old code base, so seeing them be much more tightly integrated into the style of the language is very exciting. The more important thing is that I can replace most of the memory management dance with [unowned self].