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)
3 Comments
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.