A friend writes, “So I want earch_slice, something like [1,2,3,4,5,6] / 2 == [[1,2],[3,4],[5,6]]. How do I get that in Swift?”

I recommended using a lazy sequence, consuming n indices at a  time.

extension Array {
    func sliced(by n: Int) -> AnySequence<ArraySlice<Element>> {
        assert(n > 0, "Slice must be positive integer")
        var idx = self.startIndex
        return AnySequence {
            return AnyGenerator {
                if idx >= self.endIndex { return nil }
                let nextEnd = idx.advancedBy(n, limit: self.endIndex)
                defer { idx = nextEnd }
                return self[idx ..< nextEnd]
            }
        }
    }
}

From there you can use for-in to produce [1, 2], [3, 4], [5, 6], etc:

let testArray = [1, 2, 3, 4, 5, 6]
for x in testArray.sliced(by: 2) { print(x) }

He responded, “Sure you can like [1,2,3,4,5,6].each_slice(2) and get sets of [1,2] but you have to push them somewhere, don’t you? Like tmp = []; [1,2,3,4,5,6].each_slice(2) {|x| tmp.push(x)}?”

With Swift, you don’t really have to push a sequence anywhere. It’s more a promise of data than the data itself. Just hold onto it and use it when you need it.

If you want to force things and collect results into an array, you can initialize an array with a sequence:

let result = Array(testArray.sliced(by: count))

But what you get from this is actually an array of array slices, which is what my generator produces. To build an array of arrays instead, a little functional application converts each slice into an array:

let result = Array(testArray.sliced(by: count).map(Array.init))

According to ruby-doc.org, each_slice(n) returns groups of n items at a time with the final group containing the remainder. I based my odd cases on this behavior:

// Test odd slicing
print("test", Array(Array<String>().sliced(by: 1)))
for count in 1 ... 7 {
    let y = Array(testArray.sliced(by: count).map(Array.init))
    print(count, y)
}

Not a complete list but a few I’ve made note of:

• Familiarize yourself with this list of commonly proposed ideas.
• Swift language changes should provide a highly focused tweak with limited impact and measurable benefits.
• The baseline is not whether something is “nice to have”
• Fix real problems, not theoretical ones.
• A proposal should introduce a single distinct change. If a proposal introduces multiple changes, it should be separate proposals.
• Try to break things before 3.0 and not after.
• If a feature doesn’t yet exist, show how it provides additional and non-trivial utility. (Xiaodi Wu)
• If a feature should be removed, show how is harmful to the language or contrary to the direction in which Swift is evolving. (Xiaodi Wu)
• Emphasize safety, speed, and expression.
• Swift is an opinionated language.

Chris Lattner:

We intentionally want Swift to have a common “center of gravity” and be an “opinionated” language, rather than fall to the “design by committee” approach that leads to a watered-down design.  This means that decisions are really all shades of gray and cannot be specified or predicted by algorithm.  We aim to be as transparent as possible, and explain the rationale for decisions when they come out.

That said, I and many other people on the team are highly  motivated and effected by clear descriptions of problems being solved, and why current approaches are wrong.  Particularly moving are things written by people who are clearly familiar with Swift as it stands, and who speak to why a change will make Swift better.  

Someone saying “I saw thing X in language Y, so we should transplant it to Swift” – with no further justification – is not very motivating, because Swift is much different than any other language Y, and so the tradeoffs that make it compelling in Y may not translate over to make it compelling in Swift.

Dear Erica, what is the best way to string.contains(substring) … without Foundation?

Of course, after this initial query, I was told what he wanted was really hasPrefix and not contains. This led me on a merry chase through strstr and a bunch of other ridiculous approaches, until Mike Ash suggested using startsWith and SequenceType.

The following contains ended up being pretty brute force (there’s a better version by Oisin K below) but prefixedBy does what seems to be needed. I renamed it so it didn’t overlap with the existing OS X hasPrefix.

And here’s the much nicer version from Oisin Kidney, which performs a kind of mapcdr approach.

Oisin points out that you also may want to check out this Swift version of the Boyer-Moore algorithm by Marcin Krzyżanowski.

So I probably could have spent a half an afternoon more productively but it was nice to dive back into C interop, especially touching base with pointers (strstr returns a pointer offset, so no Swift value types thank you) and remembering how to allocate, write to, and use memory directly. So not a complete waste.

It should be noted that my limited interest in diacriticals and other niceties would have come into play eventually. Using Swift-specific solutions offer a much better approach.

Swift requires parentheses when you declare a function:

f(x: T) -> U

Swift requires parentheses when you call a function

let _ = f(value)

Swift only requires parentheses when you declare a function type if the function takes 2 or more arguments:

let g1: (T) -> U // legal
let g2: T -> U // legal
let g3: (T, U) -> V // legal
let g4: T, U -> V // illegal

SE-0066 proposes to standardize function type argument syntax and discard that one legal outlier case (g2).  It introduces no changes to the syntactic sugar used for closure short-hand. All it does is clean up this one outlier case.

This proposal has led to heated discussion on the Swift Evolution list with Alan Skipp representing the surprisingly large push-back. He writes, “I’d place the ability to omit parenthesises for single args in the same category as being able to omit `self` when accessing properties. They are small conveniences that make a large difference to an entire codebase.”

John McCall writes, “To me, the unparenthesized style suggests that the input and output are peers, which feels more natural for the sort of value-to-value transform/predicate where this most commonly occurs.”

Radosław Pietruszewski writes, “To me, `func blah(f: Int -> Float) -> String` is easier to read that `func blah(f: (Int) -> Float) -> String`.” He also has concerns regarding Swift’s future should Swift adopt higher order functions.

Some list participants feel that (T, U) -> (V, W) reads more as tuple-to-tuple than 2-arguments-to-tuple. The actual tuple-to-tuple declaration is ((T, U)) -> (V, W) and would not be affected by this proposal.

Even the Void typealias has come under fire, with some members requesting that it be entirely banned.

Personally, I like SE-0066 and support its adoption. I also much prefer `func blah(f: (Int) -> Float) -> String` to `func blah(f: Int -> Float) -> String`. To me the consistency outweighs any minor savings in the odd parenthesis here and there, and clarifies the domain-to-range projection over using input and output peers.

Chris Lattner writes, “[R]egardless of why we always require parentheses on Decls and ApplyExprs, we really do (and that isn’t going to change).  Being consistent between func decls and function types is quite important IMO.”

If you’d like to jump into the discussion, SE-0066 should be up for review soon and the discussion on the initial pitch is active…and lively.

SASDOE asks, “by convention if everyone of my cases returns, should default break and there be a return after the switch or should the default return?”

If the behavior and style is consistent throughout an all-cases switch, I’d perform the return in the `default` case. Only break if there’s a significant difference in how the default case is handled. For example, when you need to perform clean-up work, workarounds, or recovery.

I promised to throw this out there for other opinions and guidance. What do you do?

Pattern or range to the left, value to the right:

if case .enumThing(let x, _) = value { ... }
if 100..<200 ~= value { ... }

The pattern matching operator is pronounced “twiddle-eek” not “bacon rocket”. Not only more fun to say but tells you the order in which to type the symbols. If you insist you’d rather “eeky-twid” instead of proper twiddle-eeking, you can always wrap your own:

infix operator =~ {
  associativity none
  precedence 130
}

public func =~<T : Equatable>(a: T, b: T) -> Bool { return b ~= a }
public func =~<I : ForwardIndexType where I : Comparable>(value: I, pattern: Range<I>) -> Bool { return pattern ~= value }
public func =~<I : IntervalType>(value: I.Bound, pattern: I) -> Bool { return pattern ~= value }
public func =~<T>(lhs: T?, rhs: _OptionalNilComparisonType) -> Bool {return rhs ~= lhs }

I’m sure this can be improved up. Feel free to offer up suggestions:

Have you ever noticed how useless Swift’s class representations are? Value types automatically  show their members and values but classes don’t. What if you could add a simple way to automatically reflect those members, like with C2?

Mike Ash threw together an adorable solution that introduces a default reflection for any conforming class:

/// A reference type that provides a better default representation than the class name
public protocol DefaultReflectable: CustomStringConvertible {}

/// A default implementation that enables class members to display their values
extension DefaultReflectable {
    
    /// Constructs a better representation using reflection
    internal func DefaultDescription<T>(instance: T) -> String {
        let mirror = Mirror(reflecting: instance)
        let chunks = mirror.children.map({
            (label: String?, value: Any) -> String in
            if let label = label {
                if value is String {
                    return "\(label): \"\(value)\""
                }
                return "\(label): \(value)"
            } else {
                return "\(value)"
            }
        })
        if chunks.count > 0 {
            let chunksString = chunks.joinWithSeparator(", ")
            return "\(mirror.subjectType)(\(chunksString))"
        } else {
            return "\(instance)"
        }
    }
    
    /// Conforms to CustomStringConvertible
    public var description: String {
        return DefaultDescription(self)
    }
}

Unfortunately, you cannot (at least at this time) conform AnyObject and get this for free (“error: ‘AnyObject’ protocol cannot be extended”).

Manuel Carlos offers this: