Hacker News Reader

Hacker News

Comment by brudgers | Hacker News Reader

Full thread

brudgers

Looks like two potentially breaking changes at source level:

https://github.com/apple/swift-evolution/blob/master/proposa...

View on HN

Don't forget the removal of the C-style for loop, along with the increment ++ and decrement -- operators.

https://github.com/apple/swift-evolution/blob/master/proposa...

The one's I linked to are listed as changes incorporated into Swift 2.2 per the announcement.

I am baffled by the for loop removal thing.

I just spent a while reading about both stride and for ... in, and I feel like there are any number of cases where I would rather use a C-style for loop.

I'm not familiar with swift, but Python doesn't have C style for loops either. People just write:

for i in range(10):

instead.

More generally, people write:

for item in sequence:

which is somewhat general (sequences include lists, dicts, strings, tuples, generators, text files and more [2]), and it covers a wide range [1] of use cases.

[1] Pun not intended.

[2] Basically, any iterable. This include custom iterables you can define, which can then be iterated over using the same standard for loop. A unifying feature of the language:

"The use of iterators pervades and unifies Python."

https://docs.python.org/2/tutorial/classes.html#iterators

what sort of cases?

Could you use a while loop instead?

I feel like (as long as the numerical case optimizes to the same thing) the for-in loop (and occasional use of the while loop) is clearer.

Theres only a case here where iterating over a parent/child relationship, and testing for nullability, its more clear with the c-style for than with a while loop:

// old

for x: Thing? = thing; x != nil; x = x.parent {

...

}

// and now

var x: Thing? = thing

while x != nil {

  ...

  x = x.parent

}

It was the only case i've really missed it.. unless theres a better way to do it that im not aware of..

But the for c-style loop for numbers is really not needed

Ideally that sort of relationship should probably be an iterator, though it's still useful for internal type implementation methods.

I am not sure if there is a name for this type of function, so I called it someFunction:

    func someFunction<T>(initial: T, next: T -> T?) -> T
    {
        var current = initial

        while true
        {
            switch next(current)
            {
            case .Some(let value):
                current = value
            case .None:
                return current
            }
        }
    }

Now you can express that idea generally, e.g.:

    extension UIView
    {
        var rootView: UIView
        {
            return someFunction(self, next: { view in view.superview })
        }
    }

I also didn't test it, so it might not work.

Of course, it would be more Swifty to create a "Parentable" protocol and write that as an extension of it!

In Swift 2.2 they're going to add warnings but they won't break previous versions of source (yet).

In Swift 3.0 they'll remove the deprecated syntaxes.

That's a fair point. In practice, it doesn't mean any less work, just longer to rewrite offending code...or not to. Deprecation still imposes debt.

Non deprecation also imposes debt. So does stagnation. So you pick your poison.

Better than the debt of a changed language/library that allows for multiple and confusing variations thanks to not removing those features (syntax, keywords, functions). It makes looking at old documentation difficult (it's wrong now), but also means that outdated guides aren't still correct (so they'll get culled or corrected more quickly) and we won't have the OpenGL situation.

Are those not going to be marked depecrated and broken in swift 3?

Changes like this are usually converted automatically by the Xcode migration tool...

Reply on news.ycombinator.com