
Swift 4.1 Released - stablemap
https://swift.org/blog/swift-4-1-released/
======
tyingq
Is "server side Swift" becoming less niche? I'm not clear on why it isn't
competing more with Go and Rust.

~~~
saagarjha
My impression has been that Swift is still very much seen as an “Apple”
language, rather than a cross platform one. Another issue is that there are
some operations that lead to crashes if they detect illegal behavior, in the
name of providing safety and consistency. Some feel that this kind of behavior
is counterproductive in a server environment because it would lead to the
server keeling over if something goes wrong.

~~~
giancarlostoro
Tooling outside of Mac I imagine is lacking as well. I also asume libraries
outside of Mac too? Strong standard libraries make languages easier to adopt.
Go had a web server out of the box removing the whole "which web library do I
use?" element out of the equation.

~~~
saagarjha
Swift on Linux has access to a substantial portion of Foundation as well as
any other C libraries, such as libc.

~~~
ttflee
There are a lot mismatches.

For example, I reported a bug about CFRunLoopMode, where the original C-based
CF used a comparison of pointer address to determine the equality of two run
mode names. The original C version actually compared using the identity rather
than equality as the commonModes was defined as a static CFStringRef
(CONST_STRING_DECL(kCFRunLoopCommonModes, "kCFRunLoopCommonModes")). Of course
this is an optimization for speed on Mac but this is, unfortunately, not
supported in Swift and its replication of CF, because in Swift it has to be a
public static String. As for today you cannot use commonModes in Linux.

~~~
saagarjha
Unfortunately Apple still considers (Core)Foundation to be outside the
auspices of Swift Evolution, which makes getting issues like these fixed much
harder.

------
protomyth
It would be helpful if Apple did a review of the sample code in the
developer's library and fix all the software that won't even compile anymore.
It doesn't help people trying to learn this language if the sample code won't
work.

~~~
dep_b
> Swift 4.1 is a minor language release. It is source compatible with Swift
> 4.0.

Nothing should break?

~~~
saagarjha
A lot of sample code is still Swift 1 or 2 code, which is not source
compatible.

~~~
ianai
Am I the only one who finds the rapid source incompatibilities problematic?
Like maybe a language shouldn’t move so fast or be better nailed down before
production.

~~~
matthewmacleod
You have two choices: bake the language fully before release, or push out what
you have and get the community involved.

I’d argue the second option is almost universally better.

~~~
ianai
Reasoning about effect aside, I walked away from an iOS project (personal)
primarily because the language moved so fast it lot me.

~~~
dep_b
Swift changed less between 3 and 4 than between 1.0 and 1.1.

The last two years or so have been fine for me.

------
melling
I’ve got a couple dozen small Swift 4 examples on Github for anyone looking
for sample code:

[https://github.com/melling/ios_topics/blob/master/README.md](https://github.com/melling/ios_topics/blob/master/README.md)

------
edragoev
RE: Server side Swift

Linux is second class citizen as far as Swift is concerned for sure. I had to
jump through a few hoops to make sure my library works on both Linux and iOS.

Just tried v4.1 and everything compiled cleanly:

[http://pdfjet.com/swift/PDFjet-
Swift-2018-03-30.zip](http://pdfjet.com/swift/PDFjet-Swift-2018-03-30.zip)

BSD licensed code, 100% written in Swift (I went through the trouble of
writing the compression code in Swift since the compression classes were
missing from the Linux distribution and some older versions of iOS ) - give it
a try.

~~~
mch82
Would it make sense to link to a Github or Gitlab repo so people can view the
source code before downloading?

~~~
edragoev
Yes - it would make a lot of sense. I have been planning to do it, however
being Mercurial user complicates things a bit.

------
mlex
I don't know if anyone who can edit the blog is reading this, but the link to
"SE-0186 Remove ownership keyword support in protocols" is wrong, it should
point to [https://github.com/apple/swift-
evolution/blob/master/proposa...](https://github.com/apple/swift-
evolution/blob/master/proposals/0186-remove-ownership-keyword-support-in-
protocols.md)

~~~
lgg
Thanks for the heads up. It should be taken care of now.

------
tinus_hn
I don't quite understand why they are putting specifics like detecting the iOS
simulator in the core language.

~~~
Someone
They want functionality that is similar to the C preprocessor’s _#if_ , but
different in that they want to require both branches to syntax check.

They also want to locally evaluate the equivalent of such _#if_ expressions
(in contrast, in C, _#if X_ requires preprocessing the file. That can mean
reading dozens of header files, and is dependent on compiler flags)

I think this is a pragmatic way to accomplish that. It restricts you to
conditions that Apple has deemed useful, but makes it easier to write good
tooling.

