I hope all of you had a wonderful last two weeks! I wanted to share that I recently tweeted reaching out to people to talk about iOS, careers and more. And it has been a really rewarding experience! It is quite different from a newsletter like the Swift Weekly Brief, but it is great to get to interact with the Swift community like this!

And with that I wish all of you another two good weeks. Until the next issue :)

有兴趣赞助 Swift Weekly Brief？点击这里

Starter tasks

• TF-447 [Standard Library] Improve TensorShape printing
• TF-448 [Standard Library] Improve Tensor type documentation

Podcasts

On the Swift by Sundell podcast, John Sundell and Michael Ilseman discuss String, its implementation, and its related APIs.

On the Swift Community Podcast, Matt Dias, Barbie Vanaiki, John Sundell, and I discuss the state of the Swift community.

News and community

Slava Pestov shared a thread on insights building a compiler, touching on how to make it performant by designing it in a way where not everything has to happen sequentially.

Commits and pull requests

Thomas Roughton merged a pull request introducing String to Float performance improvements and benchmarks.

Michael Gottesman merged a pull request introducing stronger compile-time checking of ownership in the Swift Intermediate Language (SIL), also allowing an improved Auto Reference Counting (ARC) optimizer.

Accepted proposals

SE-0255: Implicit returns from single-expression functions was accepted.

The review demonstrated clear support for this syntax for property and subscript getters, where the need to return simple single expressions is common.

On eliding the return from functions, the review feedback was more divided. While there was support from some reviewers, others expressed the view that the feature should be restricted to just getters. However, on reviewing the feedback, the core team does not see a strong case was made against applying it to functions as well, when weighed against the benefits of a single uniform rule.

Proposals in review

SE-0259: Approximate Equality for Floating Point is under review.

The internet is full advice about what not to do when comparing floating-point values:

• “Never compare floats for equality.”
• “Always use an epsilon.”
• “Floating-point values are always inexact.”

Much of this advice is false, and most of the rest is technically correct but misleading. Almost none of it provides specific and correct recommendations for what you should do if you need to compare floating-point numbers.

There is no uniformly correct notion of “approximate equality”, and there is no uniformly correct tolerance that can be applied without careful analysis, but we can define approximate equality functions that are better than what most people will come up with without assistance from the standard library.

Swift Forums

Daryle Walker wrote an “anti” pitch reasoning about why it might not be a good idea two allow protocol conformance on tuples.

If you think that slapping a protocol on a tuple is awesome, you’re probably not the only one to come up with it. The problem comes from the fact that tuple type declarations are global (modulo that a scope can access all the components’ types). What happens if you bring in a library that already had the protocol added to a tuple type you wanted to add? What happens if two different libraries do this? Would there be some kind of priority system? Since you can differentiate function overloads with protocol conformance, what if you didn’t want a particular tuple type to have a conformance? There’s no way to remove a conformance.

Alexander Momchilov shared an overview of the state of data structures in Swift.

We have just Set (unordered), Dictionary (unordered), and Array. No concurrent collections (value types solves most of the issues here, but it doesn’t solve things like the classic produce-consumer, for example), no linked lists, queues, stacks, bimaps, multimaps, or sort ordered collections.

Be sure to read the thread for some insightful discussion on the topic.

Michael Ilseman pitched a proposal for convenience syntax applying an integer offset to an existing index.

Applying offsets to indices and using relative ranges brings ease of use improvements to all Collections and is a convenient tools for reducing bugs in Int-indexed Collections. It also makes types like String more approachable in casual contexts, such as for programming puzzles and learning.

Finally

Do we have a competitor for Greg’s haikus? 🤔