Evolution

There are ten proposals on Swift Evolution that are accepted but not implemented.

I'll get back to them in a minute.

First, I want to talk about areas where our code becomes simpler if we accept certain conventions.

In the old days, before Objective-C 2, we declared an instance variable, say foo and paired it with a getter named foo and a setter named setFoo:.

Swift properties built on this convention. You could declare a property and synthesize the getter and (if appropriate) the setter.

At some point, to keep the property foo separate from the underlying instance variable, it became common to name the instance variable _foo.

Finally, if you were comfortable with this convention, you could just declare a property foo and not explicitly synthesize it. By default, the compiler would create the instance variable named _foo and the getter and setter named foo and setFoo:.

Blah, blah, blah - we don't want to hear about Objective-C, Daniel. Tell us a story about Swift.

OK. Here's one.

Suppose you have an optional named value. Then you can if-let it using

if let validValue = value { }

or guard-let it using

guard let validValue = value else { }

Many people have come to favor name shadowing. So instead of validValue, they'll use

if let value = value { }

or

guard let value = value else { }

The meaning or scope is clear.

In fact, Swift now lets us do this in closures when we're doing the weak/strong dance. We no longer have to say

if let strongSelf = self { }

we can now say

if let self = self { }

I would love to see Swift let us write these more concisely. I'd like to replace

if let value = value { }

with the syntactic sugar

if let value { }

Similarly, I'd like to replace

guard let value = value else { }

with

guard let value else { }

and

if let self = self { }

with

if let self { }

Great idea, Daniel. Why don't you propose that on Swift evolution?

I don't propose it because it is now required that if you make a proposal, you also have an implementation and I have no idea how to implement that.

Requiring an implementation to a proposal reduces the noise on the list. People can't just shout out proposals. They have to think through how the proposal might be implemented. But it also eliminates ideas from people like me. I'm thinking of how beginners approach the language and what might make it easier.

But that brings us to the ten Swift Evolution proposals that are accepted but not implemented.

SE-0239 was just accepted. It comes with an implementation. I'm confident that it will quickly make its way into the Swift codebase.

SE-0226, 0236, and 0238 are all package manager proposals and are fairly recent. I assume these will make it in to Swift soon as well.

None of the remaining six proposals have implementations.

The second oldest, SE-0068, was marked as accepted on April 28, 2016. Things went quiet for two years and then there's a comment in the associated bug that as of May, 2018, this proposal is still planned but it has no impact on ABI so it's not a priority.

The oldest yet-to-be implemented is SE-0042. This was marked as accepted on March 24, 2016. The last discussion of this bug is from December 2017. In it, the team seems to be saying that there is no ABI dependency, but that in this case because of keypaths and other changes to the language, the proposal should go through review again and would likely not be accepted as is.

I feel for the Swift team. There are these six proposals that have no implementations.

What should be done with them?

I don't know, but I think I'd like to see an update of their status so that we know which ones are due to be implemented and which ones are essentially dead - or timed out.

It may be silly, but I'd like to be able to glance at the accepted but not yet implemented list as items that are coming to Swift but aren't ready yet. If SE-0042 is essentially dead, then perhaps there should be a status that reflects this.

Swift 5 feels like a good time to clear out the evolution inbox and only keep those that are truly "TODO"s. Then again, I don't know that there's a mechanism to do so.