Tag: swift

Software Dev

The Swift Concurrency Roadmap

patmcg2 Comments

The Swift Concurrency Manifesto has now produced Swift Concurrency Roadmap (pull request). So that’s progress.

Our goal is to make concurrent programming in Swift convenient, efficient, and safe.

Once implemented, this roadmap will let you write this mess…

This way. šŸ‘

The roadmap contains “nurseries” for creating child tasks šŸ˜†, and something called “actor isolation”, starting with “basic actor isolation”. I can’t help but picture a bad actor sitting around his apartment in L.A. šŸ¤·šŸ»ā€ā™‚ļø

There’s also a solid glossary of what these terms really mean.

Via iOS Dev Weekly.

Software Dev

Syncing Made (Kind of) Easy in Swift

patmcgLeave a comment

Here’s a pretty amazing series and GitHub repo on mastering sychronizing data across iOS devices.

šŸ‘‰ Replicating Types in Swift

This is a really tough thing to do well, so this series looks incredibly helpful. The central idea is Conflict-Free Replicated Data Types (CRDTs).

I like this teaser under the headline “Where is the server?”

There is no truth ā€” decentral apps rely on trust rather than truth.

Via iOS Dev Weekly.

Software Dev

Swift Algorithms

patmcg2 Comments

Apple announced an open-source algorithms project with some very over-the-top, flashy language. šŸ˜‰

Iā€™m excited to announce Swift Algorithms, a new open-source package of sequence and collection algorithms, along with their related types.

šŸ‘‰ Announcing Swift Algorithms

This library seems to be a sort of farm league for things that might make it to big leagues of the Swift Standard Library eventually.

Swift Algorithms lets you do just about anything you can think of with a collection (or two). It lets you do stuff like rotate [10, 20, 30, 40, 50, 60] to [30, 40, 50, 60, 10, 20], or find all possible permutations of [10, 20, 30], and lots of other things like chunking, random sampling, etc. Fun. šŸ¤“

Via iOS Dev Weekly.

Software Dev

A Case For Force-Unwraping! Optionals in Swift

patmcgLeave a comment

This topic came up at work last week, with lots of different opinions on how to deal with optionals, so I was happy to see a clear opinion here.

šŸ‘‰ The Danger of Playing it Safe

For any non-programmers reading this, a force-unwrap means that if your app comes across a value that just simply doesn’t exist at all ā˜, then let the app crash right then and there šŸ’„.

This article distinguishes between development, where it’s okay (and in sometimes encouraged) to crash, and production, where it’s never okay. I like the case here for avoiding poisoned app states that can occur with nil values. Just die already, already! šŸ¤·šŸ»ā€ā™‚ļø This article basically says that some development crashes are good because they expose problems, and to take a more aggressive approach with force unwrapping.

So be assertive with forced unwrapping. If there is no case where the optional should ever be nil, force unwrap

I think I’ll start taking more chances with force unwrapping and point to this article next time it comes up in a code review. šŸ˜‰

Via iOS Dev Weekly.