
Swift 3.0 Release Process - AlexeyBrin
https://swift.org/blog/swift-3-0-release-process/
======
kev009
It looks like a really well thought out language, and the willingness to break
some things that looked like C holdovers in 3.0 for future clarity is also
interesting.

I'm wondering if Swift will hit a sweeter spot than Go (GC, weird takes or
delay on things like packaging, generics) and Rust (complexity) for userland
systems software.

~~~
hellofunk
I'm curious how Swift is getting adopted on Linux and what success folks are
having in writing Linux command-line apps or other apps?

~~~
pjmlp
IBM is betting on it as a programming language for enterprise applications.
Expect a Swift EE coming from them.

Microsoft also acknowledged that Swift support is the top request for their
iOS bridge.

~~~
codeOfRobin
They already built a flask type server side framework :

[https://github.com/IBM-Swift/Kitura/](https://github.com/IBM-Swift/Kitura/)

------
shrugger
I did not realize that we were this close to Swift 3?!

This is really awesome news. I'm pretty excited to see what they do in 3.0,
I'd love to have another language under my belt without fooling around with
NS-nonsense. That they might actually take Linux desktop seriously is really
exciting to me also.

I'd love to see a widely-used tool where games and popular apps that would
traditionally be put out on Win/Mac are able to be used seamlessly on Linux
also. On top of that, I definitely don't want to write Java, I definitely
don't want to write ObjC, etc.

Interestingly enough, I think this might even compete with Dart, which I
suspect will end up getting Wasm support and ultimately replacing Java for
android development... (Just a wild shot in the dark...) So I can't wait to
see what the Swift starts brewing up in the Concurrency department.

How exciting!

~~~
plorkyeran
> I did not realize that we were this close to Swift 3?!

WWDC is June 13-17, so they basically have to have something ready by then.
Not so coincidentally, June 13 is "4-6 weeks later" from the May 12 date for
making the release branch. Similarly, the late 2016 release for the final
version of Swift 3.0 is probably actually mid September, since the version of
Xcode with iOS 10 support has to ship before the next iPhone model.

Hurrah for marketing-driven release schedules.

------
fauigerzigerk
It's good that they are making these breaking changes now. I like the language
and the changes they are making.

The next focus should be on performance in my view. String processing in
particular is too slow to be usable for server-side tasks.

Also, I wonder what to do with Foundation in the long run. It's huge but its
design is extremely antiquated. At some point Apple will have to shed that
past where URL manipulation and file system operations are methods on a string
class.

~~~
austinz
Regarding strings...

I briefly ran the code sample you graciously provided me with a month ago
through the profiler
([https://gist.github.com/austinzheng/d6c674780a58cb63832c4df3...](https://gist.github.com/austinzheng/d6c674780a58cb63832c4df3f809e683)).

Long story short, it looks like the reflection machinery in the standard
library is improperly being used to construct String instances. Doing so,
while probably not sufficient to account for the entirety of the awful
performance, is probably quite expensive. This looks like a bug and I'll try
to dig deeper into it this week.

Swift also badly needs a native version of NSCharacterSet, even if only for
programmer ergonomics.

The developer in charge of the standard library has mentioned that that team
intends on redesigning the String API in the near future; this should provide
an opportunity to reexamine the performance implications of the current
implementations.

~~~
fauigerzigerk
That's excellent news. Thanks a lot!

~~~
austinz
After a bit more investigation, I found that if you replace the following
code:

    
    
      result.append(begin == eos ? "" : String(cs[begin..<end.successor()]))
    

with this:

    
    
      if begin == eos {
        result.append("")
      } else if let str = String(cs[begin..<end.successor()]) {
        result.append(str)
      }
    

runtime goes down from ~3 seconds to ~2.2 seconds.

This is due to a rather insidious API design decision:

    
    
      init?(_ view: String.UTF16View)
    

constructs a string out of a UTF16 view, but it can fail. If used in a context
where its type is inferred to be non-nullable, the following generic
reflection-related init is used instead:

    
    
      init<T>(_ instance: T)
    

I'm going to bring this up on the list and see if there are better ways of
doing things.

As far as I can tell most of the rest of the time is spent in the Swift native
Unicode --> UTF16 decoding machinery, and NSCharacterSet.

~~~
fauigerzigerk
I'm seeing a 23% increase in running time after making that same change.
Strange.

That's with Xcode 7.3.1 (7D1014)

~~~
austinz
Weird. I'm using the same version of Xcode, running on a trashcan Mac Pro
running OS X 10.11.4.

~~~
fauigerzigerk
OK I found the cause of that weirdness. I had slightly changed my test code
since I posted it here weeks ago. After undoing that change I'm seeing the
same thing you do.

But this raises more questions, because what I changed is the test code
generation. I'm now generating a million different strings instead of adding
the same string a million times (note the \\(i) at the end of the string):

    
    
        func generateTestData() -> [String] {
            var a = [String]()
            for i in 0..<N {
                a.append(",,abc, 123  ,x, , more more more,\u{A0}and yet more, \(i)")
            }
            return a
        }
    

The running time of generateTestData() isn't what we measure but apparently
the performance improvement you found only works if the same string is used
every time. Otherwise performance drops.

~~~
austinz
That's bizarre.

One thing I've noticed is that performing the string scanning operation is
relatively cheap. (If the splitAndTrim code is modified to not use Strings and
to return a [String.UTF16View], the runtime is around 1.2 seconds.) It's the
process of building Strings out of those UTF16 views that is destroying
performance.

I still don't know why changing the way the input data are constructed would
have that effect, except to guess that the underlying representation is
different somehow. I'll file a ticket.

~~~
fauigerzigerk
This looks to me like memory allocation / reference counting is at least part
of the problem. Slicing a UTF16View to get another UTF16View mostly likely
doesn't involve any dynamic memory allocation at all.

------
bsaul
I've had a quick look on 3.0 changes and didn't find major features related to
protocols. I'm thinking of things like more complex generic type constraints,
or a mechanism to better code against protocols ( see all videos that talk
about swift protocol oriented in "real life" and how annoying those
limitations).

Did i miss something ?

~~~
gilgoomesh
That was discussed by Apple Dev Douglas Gregor in a massive post here:

[https://lists.swift.org/pipermail/swift-evolution/Week-of-
Mo...](https://lists.swift.org/pipermail/swift-evolution/Week-of-
Mon-20160229/011666.html)

It's not clear what the schedule would be but I suspect a number of the
constraints changes will be in Swift 3.

------
Propen
I would love it if Swift could become the next-gen C++ for cross-platform
development. The Apple platforms/Linux advances are great but is it ever going
to be adopted on other platforms? I don't think Apple would care, it's mostly
Lattner & the team behind pushing the language. (bless 'em :))

~~~
proyb2
Swift is more like Java ecosystem than Rust is ideal as the next gen C++.
Otherwise, Obj-C would have been popular when it tried to compete with C/C++.
There was an article mentioning.

~~~
chillacy
> compiles to native code, specific to a platform > deterministic runtime
> performance (no GC, no JIT) > lightweight "exceptions"

Seems way more similar to C++ than java.

Also Obj-C's success or failure as a C replacement (I can't imagine using it
as one... it's not going to run well on embedded devices) has little to do
with swift's future path besides that both languages are heavily used at
apple.

The key difference may be that Chris Lattner is basically a compiler
superstar, and I think he could make it happen if he chose to.

------
hetman
I was hoping to see some changes to the error handling. The extensive use of
implicitly unwrapped properties always makes me nervous because basically we
still have the null pointer dereference problem. Also, optional chaining seems
really well geared to the use case where silent failures area OK, but things
get ugly quickly when trying to handle individual errors. Maybe I've just been
spoilt by Rust, which I've been learning at the same time, but their approach
to error handling seems much more holistic and less tacked on than in Swift.
I'd definitely like to see more done with this because that feels like the
only complaint I have with the language.

------
tormeh
Anyone know how Swift performance compared to Scala? Those are pretty similar,
I've heard. I'm pretty familiar with Scala, but not Swift. Is there any reason
to switch to Swift?

~~~
hocuspocus
They aren't so similar. Feature-wise, Swift is much closer to Kotlin, which is
(on purpose) significantly simpler than Scala.

Also if you're using Scala, there's a huge ecosystem of libraries and
frameworks that just doesn't exist in Swift. If you want native compilation,
just wait for [http://www.scala-native.org/](http://www.scala-native.org/)

~~~
proyb2
That will rely on LLVM?

------
jorgeleo
I really don't like the way that objective c express everything, so i was
looking forward to Swift.

This tells me that Swift is not ready for prime time 3 versions later:

"Swift 3.0 is a major release that is not source-compatible with Swift 2.2. It
contains fundamental changes to the language and Swift Standard Library. A
comprehensive list of implemented changes for Swift 3.0 can be found on the
Swift evolution site."

Fundamental changes??? Let me know when is stable across versions.

~~~
chillacy
Since apps include the swift runtime library though, changes won't interfere
with your current apps.

------
perfectstorm
Maybe I'm too old school but the removal of for loop is quite surprising.

for-in doesn't tell you the index of the current object so you'd have to
manually keep track of the index.

Also, x++ is a common syntax in many languages and I think a new developer
looking at Swift would try that first before using the other syntax (x += 1).

~~~
fauigerzigerk
I think what a new developer would try first isn't a particularly good
yardstick for language design. But I also think that the removal of ++ causes
some problems.

For instance, now I have this code

    
    
        mutating func next() -> Element? {
            //...
            pos += 1
            return data[pos-1]
        }
    

or alternatively

    
    
        mutating func next() -> Element? {
            //...
            let e = data[pos]
            pos += 1
            return e
        }
    

where previously I had

    
    
        mutating func next() -> Element? {
            //...
            return data[pos++]
        }

~~~
jayrhynas
FYI, a third option is

    
    
        mutating func next() -> Element? {
            //...
            defer { pos += 1 }
            return pos
        }
    

Whether it's better is a matter of opinion

~~~
stevetrewick
Nice. That's a beautifully idiomatic implementation of the original intent of
post increment, if nothing else.

------
proyb2
I was hoping all Swift professional are motivated to contribute patches,
features and tuning performance to Swift 3.0 in a swift pace instead of until
2017. Release Process is such a lengthy discussion that could have been
shorten and spending more time on improving code.

Why not using JIRA?

------
rzhikharevich
What I really miss is a proper compiler for Swift. I've encountered two bugs
in the last few days: one in the IRGen and the other one in the TypeChecker.
That can be really annoying. And that error "expression is too complex to
evaluate" is just ridiculous.

------
zerr
Any talks about Windows port?

~~~
tp101
You could take a look at
[http://www.elementscompiler.com/elements/silver/](http://www.elementscompiler.com/elements/silver/)

------
bla2
It'd be nice if they stopped breaking the language at some point. I don't want
to rewrite my program every year. I would have called that future stable
version 1.0 (like, say, Go and Rust did).

~~~
donut2d
Version 3.0 is supposed to have a much stabler API going forward. They've been
making a lot of changes even since 2.2 that really clean up the standard
library.

------
proyb2
Today I have submitted a proposal for "memorization", "memo", "memorize"
keyword for a function that allows to run only once through out the lifecycle
in Swift 3. Repeatedly execute the function will only return the same result
without having to rerun the function everytime. As far as, I don't see my
submission is being visible for discussion.

    
    
      memo func hello(fname: String, lname: String) {
        return fname.lname
      }

~~~
seanalltogether
Is this not better suited to GCD operations? dispatch_once handles this exact
use case.

~~~
johndifool
How about using `lazy` for a memoized function?

