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 :)
Interested in sponsoring Swift Weekly Brief? Learn more here.
- TF-447 [Standard Library] Improve TensorShape printing
- TF-448 [Standard Library] Improve Tensor type documentation
News and community
Commits and pull requests
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.
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
returnfrom 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
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.
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.
We have just
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.
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.
Do we have a competitor for Greg’s haikus? 🤔