Live data from Hacker News

Swift Intermediate Language Ownership Model Proposal

forums.swift.org

11–13 of 13 posts

Re: Swift Intermediate Language Ownership Model Proposal

#11
post #6
post #3

Earlier quoted context omitted.

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 t…

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.

Re: Swift Intermediate Language Ownership Model Proposal

#12

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 th…

> 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…

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/

Re: Swift Intermediate Language Ownership Model Proposal

#13
post #12

Earlier quoted context omitted.

> 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…

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/ > Swi…

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.
Post reply on HN