> Realized you need another enum case? You can't compile again until you touch all your switches. Protocol would be more expressive with an associated type? Sto

> Realized you need another enum case? You can't compile again until you touch all your switches. Protocol would be more expressive with an associated type? Stop what you're doing and write some type eraser boilerplate. Function needs to signal an error condition? Try/do/catch anywhere you call it, right now, before you run again. Need to put another type into that array? Write a new protocol and add some conformances. Changing a interface as you work in Swift immediately creates a sea of red marks, which hinders the ability to experiment. With the exception of the associated types thing which is a language limitation that would be nice to see resolved eventually, the others can be resolved with a combination of automatic refactoring (add new enum cases, etc) and a compiler mode where type errors compile down to runtime traps without preventing you from running the program. (And faster compilation in general would help as well!) These are both non-trivial to design and implement well, but I think it’s a good future direction for statically typed languages that will give them many of the benefits of dynamic languages during the prototyping phase.