Pterodactyls and thylacines: What’s evolvin’ over in Swift

Putting aside any discussion about SE-0023 (API Design Guidelines), SE-0006 (Apply API Guidelines to the Standard Library), and SE-0005 (Translate Objective-C APIs into Swift), whose discussion will probably last to the next millennium, there are some other on-going reviews to take note of.

Feb 10-Feb 16 SE-0030 Property Behaviors introduces ways to generalize common patterns, like the lazy property instead of hard-coding them into the language. I’m really excited about this one, can’t wait to see how it irons out. The discussion has focused a lot on fleshing out the proposal and tweaking how the properties will be used in-line (the original proposal uses square brackets for behavior keywords), e.g.

var [lazy] foo = 1738

Feb 11-Feb 15 SE-0031 Adjusting inout Type Decoration moves inout from modifying parameter names, to modifying types, enabling the declaration to match a method or function’s type signature:

(x: inout T) -> U // => (inout T) -> U.

Not a lot of discussion on this one, so I encourage you to go give some feedback and a vote. An obvious +1 from me.

Feb 11-Feb 16: SE-0027 Expose String Code Units Initializers enhances developer-facing string-to-byte and byte-to-string calls. It extends them from the currently public pair of C-strings initializers to add and adapt currently private _fromCodeUnitSequence(_:input:) calls. Looks good to me.

Feb 12-Feb 17: SE 0024 Optional Value Setter introduces ??=, a conditional setter that mimics Ruby’s ||= operator.  It performs an assignment if and only if the optional on the left of the operator is currently nil, and will not overwrite an already set value.

I’m not sure how I feel about this one, as I don’t quite get the utility and benefit, and it confuses the use of the ?? nil-coalescing operator, which unlike this ??= one always produces a non-optional. I’m thinking I’m -1 on this.

I’d sort of prefer an operator that assigns a non-optional if and only if the right side of the assignment is non-nil, but that’s not what’s being proposed. You can read through the on-list discussion here.

Other upcoming reviews:

Interesting on-list discussions:


  • I do have extensions for both ??= and =?? 🙂

  • ??= makes perfect sense to me.
    a += 1 a = a + 1
    a ??= 1 a = a ?? 1

  • Hmm… It erased part of my comment/formatting above. I was basically saying ??= is consistent with += etc… so it makes sense to me.

    That said, I do agree that the opposite case =?? (where it only assigns if the rhs is non-nil) is 1000x more useful.