
Small but significant improvements in Swift 5.1 - ingve
https://www.swiftbysundell.com/articles/5-small-but-significant-improvements-in-swift-5-1/
======
josephg
This is a great release, but the thing I'd really like the swift developers to
focus on is performance. It seems surprising given how similar swift is to
rust, but I've heard some reports of programs spending 60% of their time
updating reference counts. I'm not sure the best way to fix that - do
programmers need a way to opt out of swift's default memory model? Is there a
way to elide some of those checks in the optimizer? But it seems like for
small objects something like that would make a big difference in performance.

This probably doesn't matter much when making iOS apps, but it would make
swift much more useful in other domains (like as a web server).

~~~
NobodyNada
Joe Groff (one of the Swift compiler engineers) says they’re working on that:
[https://forums.swift.org/t/swift-
performance/28776/8](https://forums.swift.org/t/swift-performance/28776/8)

> [...] there are already substantial improvements to RC optimization in 5.1
> (and even more in top-of-tree). Using Unmanaged is "cheating" in a sense
> because it's unsafe, and it should not be necessary in normal circumstances
> to get adequate performance from idiomatic code—if it's safe to use
> unmanaged references, then the compiler should know that and avoid reference
> counting in the first place. The current Swift implementation is still
> nowhere near representative of the performance that should be possible,
> since we've been primarily in the "make it work" phase of development, and
> are only now starting to get into the "make it fast" work.

------
thefj
I must have missed the official announcement[0], module stability is a very
welcome change.

 _Swift 5.1 enables the creation of binary frameworks that can be shared with
others leveraging the language’s added support for module stability._

[https://swift.org/blog/swift-5-1-released/](https://swift.org/blog/swift-5-1-released/)

------
elpakal
A huge(!) release for a minor version. I’m most excited about default values
for memberwise initializers, opaque return types and property wrappers.

~~~
soganess
Same for the member-wise defaults! Especially in concert with optionals. I
hate having callers explicitly pass in nil, but I'm also not fond of provided
a convince initializer, as it is one more thing to change when you add a new
member to a struct.

~~~
elpakal
I remember hearing at WWDC that memberwise defaults were added to Swift by a
student. Apparently pitched the idea in the forums, then went straight PR on
it!

------
melling
You no longer need to use a return keyword for single expressions:

    
    
        func add(_ x:Int, _ y:Int) -> Int { x + y }
    
        let z = add(2,2)
    
    

Might not seem big, but it's nice to removed unneeded boilerplate.

~~~
virtualwhys
I don't use Swift, what's the point of the underscores in the method
declaration?

~~~
melling
Without them, you’d need to name the parameters.

let z = add(x:2, y:2)

~~~
virtualwhys
Ok, but I still don't understand, why would you have to name the arguments to
the method?

Are there other languages with this type of method declaration/use site
syntax? If so, what's the advantage?

~~~
pryce
The advantage is clarity in the calling function.

With type safety checks, you're mostly eliminating a class of problem by
ensuring coders don't call the function with some argumetn of a type they
didn't mean to.

But suppose I have a method that takes 5 different strings and performs some
computation on them - the type safety check doesn't help me there.

In functions that take multiple arguments of the same type, it can be easy to
be mistaken about the intended order of parameters, for example passing the 5
strings (name, address, level, phonenumber, cellphonenumber instead of in the
order the function expects (name, address, phonenumber, cellphonenumber,
level).

Named parameters -if using meaningful names- make it clear in the calling
function the semantics of which parameter has which meaning, so the above
mistake gets caught at compile time instead of (worst case) not at all.

Of course, in functions with arguments of heterogenous types they're probably
overkill.

------
saagarjha
> Since Swift optionals are implemented using the Optional enum under the
> hood, we’re no longer able to perform the above kind of optional pattern
> matching on any enum that contains either a some or none case — since those
> will now conflict with the cases that Optional contains.

Wait, so if I wrote my own custom enum with .some and .none cases this will
not work correctly? This seems like an overly broad scope; why can't the
change have only affected Optional.some and Optional.none?

    
    
      public extension Sequence where Element: Identifiable {
          func keyedByID() -> [Element.ID : Element] {
              var dictionary = [Element.ID : Element]()
              forEach { dictionary[$0.id] = $0 }
              return dictionary
          }
      }
    

Perhaps this could use Dictionary(grouping:by:)?

------
nurettin
Member initializer syntax at version 5.1? I thought swift was on par with
kotlin and typescript, or at least python in terms of features.

~~~
andrewbarba
It's specifically around default values.

If you use any language long enough you will think, hey it would be nice to
have X. Alejandro (in high-school at the time) thought exactly that and
implemented it himself - [https://github.com/apple/swift-
evolution/blob/master/proposa...](https://github.com/apple/swift-
evolution/blob/master/proposals/0242-default-values-memberwise.md)

You could almost argue the real feature here is how open the community is to
additions like this, and there's no need to wait for people at Apple to do it.

~~~
innagadadavida
Pretty neat and definitely very different from the Go community.

