Swift Intermediate Language Ownership Model Proposal | Hacker News Reader

Swift Intermediate Language Ownership Model Proposal

forums.swift.org

81 pointspjmlp11 comments

I am only vaguely familiar with Rust ownership model and last I programmed Swift was version 3.x.

Does anyone have any thoughts on where Swift is going with ownership models in relation to Rust? What sort of different priorities will these languages set?

It has been my impression that Rust seeks to be more of a tool for the more experienced programmer while Swift attempts to be more user friendly or appeal more to the average programmer.

I would thus speculate that Swift team will never try to force Swift users to understand ownership models the way Rust developers have to. What do you think? Where can we expect this to be going?

> It has been my impression that [...] Swift attempts to be more user friendly or appeal more to the average programmer

I would dispute this somewhat. I really think Swift was conceived to be a better C++. The stated "world domination" goal has always included systems programming. (I don't find it realistic personally that a single language can reasonably span from writing an OS to utility scripting, but that's been the pitch.) I would guess that, privately at least, Swift sees Rust as a competitor.

That said, the Swift core team does take learnability and what they call "progressive disclosure" seriously. They've emphasized that this particular feature should be something that most Swift users won't need to know or think about. They definitely do spend time and effort on people who are new to the language.

The other thing that may contribute to the impression that Swift is "less advanced" is simply its userbase. Its life started in GUI application development for Apple platforms and that's also key to its success -- iOS is hot right now. That's the majority of its deployment, and I think it will remain so for quite a while.

We iOS devs may be average or not, but most of the code we write is not high-performance mission-critical algorithm-laden wizardry, just grabbing some JSON off a REST endpoint and animating the information into a table view. ;)

Well, this is Apple's official point of view on Swift's purpose.

> Swift is a successor to both the C and Objective-C languages. It includes low-level primitives such as types, flow control, and operators. It also provides object-oriented features such as classes, protocols, and generics, giving Cocoa and Cocoa Touch developers the performance and power they demand.

Taken from https://developer.apple.com/swift/

> Swift is intended as a replacement for C-based languages (C, C++, and Objective-C).

Taken from https://swift.org/about/

Yes, good point, thanks. But this is not quite what I was intending to say. The character of Swift is not very C- or ObjC-like. C's philosophy is largely (to borrow from Python) "we are all consenting adults here": raw flexibility is the name of the game. ObjC's class system is famously late-binding and runtime-malleable, and it carries all the flexibility of C. These are things that Swift eschews.

I'll be honest, I don't understand enough about ownership models, or advanced language design to answer this incredibly well.

Chris Lattner commented on this almost directly during an interview [0]:

>The promise, the dream, is to instead say, "Hey, if you are a sufficiently advanced programmer and you know how this stuff works, we can give you a new option. Instead of dropping down to unsafe constructs, you can actually just use more static type information annotations in your code.”

And, in general, Swift has been designed with progressive disclosure as a primary philosophy.

[0] -http://atp.fm/205-chris-lattner-interview-transcript/#rustme...

The idea is that Swift will still use a reference counting GC as the main way, however there is the additional possibility to use ownership annotations for low level control, but not as strong as it is done on Rust’s case.

There are a couple of WWDC 2018 sessions about it.

Is the approach here effectively about extracting from the (existing) implementation a kind of operational specification to help ensure the non-existence of undefined behavior ...?

Not, it is a means to better support the ownership model, similar to Rust, that was introduced in Swift 4.0.

But note that the full ownership model is not exposed in Swift. It is only present in the Swift Intermediate Language (1) - an intermediate language used by the Swift compiler to perform diagnostics and Swift-semantic aware optimisations before emitting LLVM IR bit code.

It is likely that more ownership features will be added to the Swift language, but it is out of scope for the next major version as you can see on this dashboard: https://swift.org/abi-stability/

(1) https://github.com/apple/swift/blob/master/docs/SIL.rst

My guess is that they will make this explicit in SIL first, to be able to add that into the language syntax later.

For instance, as far as i know, the auto ref-counting model is on SIL, who injects lower level refcounting ops into the intermediate code, before going through the LLVM pipeline.

This was a good thing to do, now that they are willing to open the ownership model to other kinds of ownership. Which will probably be controlled by the dev in the end.

At least, that's what i understood from what i read. Its SIL only for now, but it means what is it implying it means. A opt-in manually controlled ownership model when ref-counting is not the best approach.

The acronym is S.I.L.O.?

Reply on news.ycombinator.com