
What's new in Swift 4.1 - OberstKrueger
https://www.hackingwithswift.com/articles/50/what-s-new-in-swift-4-1
======
PopsiclePete
Is this used outside the Apple eco-system much? I admit I haven't looked at
Swift in 2 years or more.

I find the omission of features like namespaces really strange. I realize that
namespaces don't jive with how Obj-C and Obj-C frameworks see the world and
that Swift and Obj-C need to play together, but dealing with global namespace
pollution and collisions in 2018 just seems...sad? They're hobbling the
language in various ways due to NS*/Cocoa framework stuff.

Another weird omission is lack of any kind of concurrency story. Right now,
this just seems like Apple's "me-too" version of Java/C#, but what does it
actually bring to the table that would make it a worth-while investment if I'm
not an iOS developer?

~~~
eunoia
> Another weird omission is lack of any kind of concurrency story

Grand Central Dispatch (GCD or libdispatch) is generally the concurrency story
on Darwin platforms. There has been an ongoing effort to port it to Linux. Not
sure how complete that is but I linked the Github below. Swift on Linux still
has a lot of rough edges in general.

[https://developer.apple.com/documentation/dispatch](https://developer.apple.com/documentation/dispatch)

[https://github.com/apple/swift-corelibs-
libdispatch](https://github.com/apple/swift-corelibs-libdispatch)

~~~
aplummer
A good read on the future of Swift concurrency is this from Chris Lattner,
[https://gist.github.com/lattner/31ed37682ef1576b16bca1432ea9...](https://gist.github.com/lattner/31ed37682ef1576b16bca1432ea9f782).
I think currently still slated for Swift 5

~~~
bsaul
This is going to be very interesting to watch. They decided to add concurrency
after having built an extraordinary complex language. Something people like
rob pike thought would be very hard to do (and as both a go and a swift coder,
i must say i tend to think he's probably got a point).

~~~
gilgoomesh
The concurrency model was planned before the first betas but has been delayed.
The devs always knew how they wanted concurrency to work.

~~~
bsaul
I didn't know that, but i'm not surprised because chris lattner clearly knows
what he's doing. I'm still curious to see how it ends up integrating in a
language that's been evolving a lot since its design.

Saying that they managed to keep concurrency orthogonal to the rest of the
language means Rob Pike was "wrong" (or at least what i understood from his
point).

However, after reading the conversations around the async proposal, it seems
to me on the contrary that it is very tightly related to other parts (such as
error throwing mechanism, GCD library and syntax in general).

We'll see. I wish i didn't have the feeling swift core team is understaffed,
because at least for iOS development it is really a joy to program with.

------
beefsack
This is great news for developers who use Apple products.

I'm happy they're trying to improve the cross-platform story but I'm not sure
I could ever completely trust the ecosystem when it's so tightly bound to
MacOS/iOS (standard library still not complete, 3rd party libraries may only
work or be well tested on Apple platforms, new features may take time to land
on other platforms.)

~~~
Cyberdog
> standard library still not complete

Define "complete." I would say if you count the Foundation library - which
ships with Swift - as part of the standard library, things are pretty darn
complete.

> new features may take time to land on other platforms

Not as far as Swift itself is concerned. Ever since Swift went OSS, new
releases land for Linux and macOS at the same time.

~~~
beefsack
There is a significant amount of functionality in Foundation unavailable on
other platforms:

[https://github.com/apple/swift-corelibs-
foundation/blob/mast...](https://github.com/apple/swift-corelibs-
foundation/blob/master/Docs/Status.md)

~~~
Cyberdog
Numbers-wise, yes. Day-to-day-usage-without-a-trivial-workaround-wise, no.

------
adamnemecek
conditional conformance is a game changer.

~~~
O_H_E
Does that exist in other languages, a quick look doesn't show up anything for
python/c++

~~~
dahauns
Dunno about python (but then again it's a dynamic language...), and it's been
an endless discussion for c++ AFAIK.

Other than that it's actually rather common in statically typed languages
(except Go ;P). From the top of my head e.g. Java, C#, Typescript, Kotlin,
Rust, Haskell all offer constraints for generics.

~~~
masklinn
I think your comment is a bit… not sure what the word is, under-appreciating
the feature? Over-selling some languages?

Because AFAIK Java (or C#?) does not have constrained _interface_ conformance,
it only has bounds on functions (which Swift already had). That is you can say

    
    
        static <T extends Comparable<? super T>> void sort(MyList<T> list)
    

such that you can only sort lists of comparables, but you can't say

    
    
        class MyList implements Comparable<T extends Comparable<? super T>>
    

such that MyList implements comparable IIF its items are comparable.

~~~
dahauns
Agh, yes. I already regret putting Java in that list with its wonky
implementation. :)

But it certainly works with others, e.g. something like this:

    
    
        public class SortedList<T> : ICollection<T>,IEnumerable<T> where T : IComparable<T>

~~~
masklinn
Is that C#? So it does have optional interface implementation? TIL.

~~~
dahauns
Huh? I'm not sure where you're getting at.

~~~
masklinn
I'm only asking if the snippet you posted is C# or something else, and noting
that if it's C# I have learned something new about the language.

Except now that I look at it more specifically, it looks like a bound on the
class's generic parameter rather than a condition on the interface
implementation?

As in you're defining a SortedList class which implements ICollection and
IEnumerable but requires T:IComparable, not defining a SortedList class which
implements IEnumerable _if_ T is IComparable.

And if that reading is correct, Java can do it just fine:

    
    
        class SortedList<T extends Comparable<T>> implements Collection<T>, Iterable<T>
    

however it's got nothing to do with conditional conformance.

------
dennisvennink
Implementing conditional conformances alone removed a lot of duplicate code
from the standard library. I always like to think that the amount of gyb[^1]
files in the source code is a good indicator of how far Swift is in its
development.

[1]: gyb, a template processor, is a workaround for features that the standard
library needs, but that are not (completely) implemented yet.

------
tabs_masterrace
Can anyone explain whats the reasoning behind renaming flatMap?

~~~
masklinn
The SEP makes it pretty clear: [https://github.com/apple/swift-
evolution/blob/master/proposa...](https://github.com/apple/swift-
evolution/blob/master/proposals/0187-introduce-filtermap.md)

Basically, they did not rename flatMap they renamed _one specific overload_ :

    
    
        Sequence.flatMap<U>(_: (Element) -> U?) -> [U]
    

or in Haskell parlance

    
    
         mapMaybe :: (a -> Maybe b) -> [a] -> [b]
    

which _filters_ after mapping more than it flattens (in fact the Rust and
OCaml versions are called filter_map). The issue is that due to Optional
promotion you could misuse flatMap (where you should have used map I guess)
and could get this filtering behaviour unexpectedly instead of the
straightforward mapping you would be expecting (it also led to extra branches
and optional wrappings and unwrappings).

------
hacker_9
_" things that didn't work before will now"_

Just the words I want to hear when I upgrade my programming language by one
minor version.

~~~
melling
You are taking something out of context and commenting just to be snarky. This
is not a case that you commonly use:

var left: [String?] = ["Andrew", "Lizzie", "Sophie"]

var right: [String?] = ["Charlotte", "Paul", "John"]

left == right

This works fine, for example:

var left: [String] = ["Andrew", "Lizzie", "Sophie"]

var right: [String] = ["Charlotte", "Paul", "John"]

left == right

