Swift Priorities

/

Swift is very much a work in progress, and Apple have even told us that they expect to change the syntax. Outside of Apple many are asking themselves when the right time to get engaged with Swift is. For us, the fact that Apple are proactively looking for feedback on every aspect of Swift is a key input to that decision; how are we to give constructive input if we haven't used what's there? 

But with that in mind, we've just submitted a range of radars highlighting things we'd like to see. We submitted far more than five, but it stimulated the discussion about what the top five would be (how very High Fidelity of us). So here they are: 

  1. Asynchronous Operation Support There's no doubt closures (and blocks before them) make it so much easier to develop and use APIs asynchronously. They can do lots of other jobs too, so it's great to see some clean support for them. However advances from C# show us that the spaghetti that can ensue trying to deal with failures in chains of operations can be avoided. Whilst similar features like promises are interesting, they are really just a closure pattern. Modern day processors with multiple cores, responsive UI, there are plenty of reasons for language level support of syntax that makes this easy (or easy to write and get right). 
  2. Access control: Public, protected, private... if we are to design good interfaces we need to hide what's inside from users of our frameworks (and that includes us). Apple have confirmed this is coming... when... that may be a different question. Either way given we know it's coming I don't want to go on about it, but it's important. 
  3. Metadata: The ability to annotate objects, in the run time as well as at compile time, is one of the most interesting developments for me in recent years (at least in main stream languages). The uses, for me, far out weigh something like reflection. Reflection really only has one core use-case; to enable a job to be done with a class, without the "worker" having any knowledge about the class before hand. The issue is that the only information available is that captured by the language. You need meta-data beyond that to tell you what the data means. For example for a persistence framework.... do I want that collection to be persisted? Is it an in memory map kept for runtime performance? After lamenting the lack of reflection, I'm left feeling that actually I'd much rather have requirements to annotate my code, than to simply reflect. So reflection, whilst nice, is off the short-list. Query-able metadata first please, there's nothing we couldn't do with just that. 
  4. Language Level Queries This beat out regular expression support because again we think it's a super-set. String matches regex, Collection contains value, Item.children Contains otherValue. All of these would allow classes and their metadata to be found and sorted. We've got so much in place that would make this work wonderfully (and having it would knock another reflection use-case on the head). I know, we have NSPredicate, but it's all so heavy. Let's have a light-weight way to traverse our data-models leveraging the available metadata (from properties to annotations)
  5. Playgrounds to Testing Grounds OK OK. It's not a language feature, but ahead of everything else we've thought of this stood out as something we now almost instinctively wanted to do. Here's the pattern that has established itself over the last week. Build something in playground, test out the idea "live", once we are happy, create the .swift files and away we go. As you look at the code left in the playground.... it looks like tests. If I could just highlight a block of code, and call "Create Test" it would be awesome. It could even use the values or state you'd see in the inspector for validation. 

What are your five?