Last week in Swift Evolution

Week of Feb 8, 2016

Published on

Here’s a summary of selected updates from last week from the Swift Evolution repo and mailing list:

Review discussions

  • Property behaviors

    Previously: Week of Jan 11.

    Currently, lazy is a feature that’s baked into Swift compiler. Joe Groff is trying to generalize it out of the compiler, thereby enabling us to write our own lazy or create other lazy-like annotations on properties.

    Per the proposal, you can say var [lazy] foo = 42, and specify the implementation of how lazy properties should behave as code. Specifically for lazy, I would expect this implementation to be in the Swift Standard Library. We can also implement our own behaviors like mycustomlazy or cached.

    This is a huge change to how Swift properties work, and so the review period extends to the whole of February.

  • Optional Value Setter

    James Campbell proposes to add a new operator ??= for assigning a value to an optional variable only if the variable is nil.

    var i: Int = nil
i ??= 42 // Assigns the value 42 because it was nil earlier

    This is the same as doing i = i ?? 42, but uses the variable just once, making it more typable, less error prone and easier to read (especially when it’s a long variable with sub-paths).

  • String from Code Units

    Previously: Week of Jan 11.

    Currently, creating a Uncode String from a sequence of bytes works cleanly for just one case: null-terminated UTF-8 bytes.

    Zachary Waldowski proposes to create String instances from an arbitrary sequence of code units with an arbitrary encoding.

    This addresses a gap in the current string API and is very likely to be accepted. There’s a working implementation in the PR.

  • Adjusting inout Declarations for Type Decoration

    Previously: Week of Dec 21.

    Joe Groff and Erica Sadun propose that the inout decoration in function declarations be moved from the label side to the type side:

    // Current syntax
func foo(inout x: T)

// Proposed syntax
func foo(x: inout T)

    This has been discussed in depth before, and this syntax was the most favourite, so this proposal too is likely to be accepted.

Accepted proposals

  • Remove passing function arguments as tuples

    Previously: Week of Feb 1.

    I had thought this was an odd and hardly used feature that nobody would miss if removed, but I was wrong – Brent Royal-Gordon uses this feature “reasonably often”. He said:

    Tuple splat allows you to write generic functions that work with a function of any arity. … Even something so simple as a function composition operator is impossible to write without it.

    Nevertheless, since this proposal is accepted, tuple splatting is going away in Swift 3.0 without an immediate replacement. Joe Groff writes:

    … maintaining this behavior in the type checker is a severe source of implementation complexity, and actively interferes with our plans to solidify the type system. We feel that removing the existing behavior is a necessary step toward stabilizing the language and toward building a well-designed alternative feature for explicit argument forwarding in the future.

    Consequently, Brent has started a discussion on alternative ways to pass tupled arguments to functions. The alternatives he came up with are:

    1. A special parameters label: concatenate(parameters: tuple)
    2. An apply method on functions: concatenate(_:to:).apply(to: tuple)
    3. A splat operator with * or !: concatenate(_:to: *tuple)

Discussions

  • Binary compatibility of Swift libraries

    Previously: Week of Jan 4 (See: Other).

    Jordan Rose is inviting comments on the Swift Library Evolution document:

    Our current design in Swift is to provide opt-out load-time abstraction of implementation for all language features.

    This implies that all language features will be part of the ABI, and will be available for use across module boundaries.

    [We will design] the language and its implementation to minimize unnecessary and unintended abstraction:

    1. Avoiding unnecessary language guarantees and taking advantage of that flexibility to limit load-time costs.
    2. Within the domain that defines an entity, all the details of its implementation are available.
    3. When entities are not exposed outside their defining module, their implementation is not constrained.
    4. By default, entities are not exposed outside their defining modules. This is independently desirable to reduce accidental API surface area, but happens to also interact well with the performance design.

    The earlier discussion on making classes final by default for libraries (previously: Week of Dec 21) is a reflection of the these points.

    Erica Sadun wrote about this request for comments in her blog.

Other weeklies

  • Jesse Squires’ Swift Weekly Brief Issue #9 talks about open-source Swift happenings last week.

    In particular, Jesse talks about the discussion on garbage collection in the mailing lists which is a discussion that I haven’t read up on.

Update: See also Erica Sadun’s excellent roundup of last week.