
Implemented proposals for Swift 3 - okket
https://github.com/apple/swift-evolution#implemented-proposals-for-swift-3
======
kinofcain
One thing I don't see in this list (though maybe I'm missing it) is the
ability to expose a Swift function as a function compatible with the C ABI.
Something like extern "C" in C++ or no_mangle in Rust.

You can pass @convention(c) blocks around as C function pointers, but you
can't currently call directly into a Swift library from C code. That makes it
difficult to do things like expose platform-specific functionality to a shared
C library using Swift.

Right now you have to implement the C function inside an Objective-C file, and
then have your Objective-C code call your Swift code, or you have to change
all your interfaces to allow injection of function pointers for all external
dependencies.

It's the kind of thing that makes staying with Objective-C attractive for that
type of stuff, but Swift in general has been a solid improvement, and I'd like
to not have to give that up.

~~~
stevetrewick
Seems to be being worked on, an attribute @_cdecl has been merged into master
[0] and seems to compile in the current beta of 3.0 [1] although I haven't
tested it.

[0]
[https://github.com/apple/swift/commit/013aad13d4245a012cfb76...](https://github.com/apple/swift/commit/013aad13d4245a012cfb762b7edccf92013b3609)

[1]
[http://swiftlang.ng.bluemix.net/#/repl/d68be430e72609717f718...](http://swiftlang.ng.bluemix.net/#/repl/d68be430e72609717f718006aa0ae137eae872ca7a0b7e8141b351770b0c9eac)

~~~
kinofcain
Awesome, thanks so much for pointing that out.

~~~
stevetrewick
You're welcome. I have a custom mouse cursor a11y app that has to use some
nasty old C callback API, which is exactly the PITA you describe, so I've been
keeping an eye out.

------
mmastrac
I'm surprised they removed x++ from the language. This is always a big
frustration when I'm writing Python code.

~~~
kinofcain
Rust did too. There's probably a pie chart somewhere of time lost to having to
type out "foo += 1" vs number of hours lost to people screwing up operator
precedence for foo++ or ++foo. (EDIT: as munificent points out this is
actually a combination of operator precedence and sequence points)

The pie chart is probably severely lopsided.

EDIT: Since the main problem is the precedence of the post increment/decrement
operator, I would have preferred to see them get rid of that one and keep
++foo but overall not much of a loss.

At least they didn't get rid of the ternary operator like Go did...

~~~
munificent
It's not about operator precedence, it's about sequence points.
Assignment—including in ++—is a side-effecting operation. An expression form
that does side effects can lead to very confusing code like:

    
    
        foo(a++, a++);
    

What values get passed foo()? In some languages, it's undefined (!). In
others, there is a well-defined answer, but even there the answer may not be
_intuitive_. Removing assignment expression forms avoids this. Note that even
"=" is a statement in Go.

It does sacrifice a little expressiveness. But in languages that have
dedicated syntax like ranges for iterating over sequential numbers, the ++ and
-- operators end up pretty rarely used so it's no big loss.

~~~
masklinn
> Note that even "=" is a statement in Go.

In Python and Rust as well.

~~~
dbaupp
Nitpicking: assignment is an expression that returns () in Rust, meaning
`foo(a = 1, a)` is valid if foo has a signature like `fn foo(x: (), y: i32)`.
However, arguments are (mostly) defined to be evaluated from left to right.

------
orbitur
How do we get to the PRs/commits for the proposals? I see a link to a JIRA
issue, but the issue doesn't link to anything in Github.

~~~
jayrhynas
This gets you pretty close:
[https://github.com/apple/swift/pulls?q=is%3Apr+SE-](https://github.com/apple/swift/pulls?q=is%3Apr+SE-)

------
Negative1
Curious; have they made any statements on their versioning? I've seen mature
projects years in development that are still 0 for major and in the teens for
the minor version. Despite breaking changes Swift is now a 3.0 project?

~~~
natthan
I believe that they are using Semantic Versioning 2.0.0[1] as discussed in the
Swift Package Manager Project's Website[2] under "Importing Dependencies":

> Given a version number MAJOR.MINOR.PATCH, increment the:

> MAJOR version when you make incompatible API changes,

> MINOR version when you add functionality in a backwards-compatible manner,
> and

> PATCH version when you make backwards-compatible bug fixes.

> Additional labels for pre-release and build metadata are available as
> extensions to the MAJOR.MINOR.PATCH format.

[1] Semantic Versioning 2.0.0 [http://semver.org](http://semver.org)

[2] Swift.org - Package Manager [https://swift.org/package-
manager/](https://swift.org/package-manager/)

------
thurn
Still no way to export structs or enum-ADTs to Objective C code, though.
Really makes it hard to write idiomatic Swift APIs that can be called from
Objective C.

~~~
pjmlp
Given the legacy status of Objective-C, when does such use case matter?

The way forward is to call existing Objective-C from new Swift code.

The only WWDC talks with Objective-C code were related to the new features to
make Objective-C easier to call from Swift.

------
paxcoder
Let me guess: It's not a complete standard library?

~~~
valleyer
They have publicly said that they want to keep the standard library small, and
swift-corelibs-foundation is available and open-source.

~~~
paxcoder
It is incomplete: [https://github.com/apple/swift-corelibs-
foundation/search?ut...](https://github.com/apple/swift-corelibs-
foundation/search?utf8=%E2%9C%93&q=NSUnimplemented%28%29)

