I am back! I had the most wonderful time at WWDC, learning a lot of and meeting awesome people. I want to specifically thank all those that have shown their gratitude for the weekly brief, it’s much appreciated!
Without further ado, here’s this week’s news on the Swift.org open source projects.
- SR-7984 [Compiler] Constraint to concrete type using
:should offer a fixit
- SR-8012 [Standard Library] Remove
- SR-8049 [Swift for TensorFlow] Open source S4TF unit testing with a remote TF session
In episode 64, Jesse and JP discuss
Never, the return type of functions that do not return normally.
News and community
Commits and pull requests
The core team has accepted this proposal, with one revision:
numericValueproperty should be a
Double?rather than a
nilfor non-numeric values rather than
In the review thread discussion, many names were considered, and the core team agreed that
KeyValueListwas proposed) is a best name suggested on the thread for this type.
- Improved scheme generation logic
- Local dependencies
- Automatic Xcode project generation
- System library targets
- Embeddable Xcode projects
This proposal introduces namespacing for fatal errors. It provides an umbrella for common exit scenarios, modernizing a holdover from C-like languages.
fatalErroris arguably insufficient for a multitude of real world uses including discoverability, extensibility, and significance. Swift lacks a modern extensible solution that differentiates fatal error scenarios.
There is a small but important tangle of issues around the interaction between
FloatingPointprotocols and the IEEE 754 standard that I would like to attempt to resolve.
This is a list of some evolution ideas for the package manager. Once the details of an idea are fleshed out and there is a full proposal, it can be scheduled for the swift-evolution process. It is important to note that not every idea on this list is guaranteed to become an official feature, and it all depends on where the design discussion leads us. Also, this is not meant to be an exhaustive feature list, if you have an idea for a feature that you think will be a valuable addition to the package manager, feel free to start a discussion about it.
If you’re interested in participating in a particular evolution idea, please familarize yourself with the existing discussion on that topic and start participating in the discussion thread of that idea.
I’ve been thinking about a way of creating an array that would let us access the buffer of uninitialized memory, so that we could implement algorithms that don’t necessarily know the size in advance or need access to noncontiguous parts of an array.
There is currently no way to work with a buffer of uninitialized memory that then becomes a fully memory-managed
Array. This limitation means that operations that don’t know the final size of their data in advance, or that need to access noncontiguous parts of an array, are less efficient than necessary, often requiring an extra copy. This proposal suggests a new initializer for
ContiguousArraythat would provide access to a newly created array’s entire storage buffer.
So, everyone knows what a string interpolation looks like:
But let’s talk about some other things you might write, perhaps because you hate compiler engineers. What do you think these do?
Most people I’ve spoken to say “produce an error message”, and they’re right about #1—it produces the error “expected expression in list of expressions”. Maybe not the clearest message, but it’s not technically wrong.
But the other three? They actually compile without complaint and form a tuple.