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:

• Feb 16-19: SE-0035 Limiting inout capture to @noescape contexts
• Feb 18-23: SE-0033 Import Objective-C Constants as Swift Types
• Feb 17-22: SE-0034 Disambiguating Line Control Statements from Debugging Identifiers

Interesting on-list discussions:

• Case conventions for initialisms (vs acronyms, white paper)
• Enum leading dot prefixes (proposal discussion, language quirk)
• Renaming the #line control statement (proposal discussion)
• Overridable Members in Extensions  (pitch)
• Delegates that conform to protocols (practical, Cocoa/touch-y)
• Extending warn_unused_result to closures (plug a hole)
• Compile-Time Code Execution (to build compute-once, use-often lookup tables, for example)
• Avoiding the Weak/Strong dance (common pattern that is screaming out for fixing)