This is very interesting, but it'll probably be a little while before I can fully get my head around it.
One query though; an example mentioned is adding @owns(Element) to the Generator protocol, but associated types feel a little different to me; you mention using the strong keyword as an alternative, but I wonder if that might actually be a better fit for the associated type case, while @owns works elsewhere, or perhaps strong could even be made a shorthand for simpler cases? Just thinking out loud I guess, it would be nice to hear the thought process around associated types; most (possibly all I don't remember) cases in which I've used associated types it has been for strong references, so it seems like that should be as easy as possible to do under the new opt-in approach. But yeah, I generally agree that this ought to be opt-in, as it's an area I do stumble upon quite a bit myself (in many languages). > On 30 Jul 2016, at 02:42, Andrew Bennett via swift-evolution > <[email protected]> wrote: > > I'd like an opt-in way to verify and prevent unintentional strong references > in Swift. > > This can be used to verify ownership structures, and ultimately avoid retain > cycles. > > Read a draft proposal here: > https://github.com/therealbnut/swift-evolution/blob/therealbnut-explicit-ownership/proposals/NNNN-explicit-ownership-type-attribute.md > > <https://github.com/therealbnut/swift-evolution/blob/therealbnut-explicit-ownership/proposals/NNNN-explicit-ownership-type-attribute.md> > > TL;DR: > > If you have any questions please read the proposal before asking here. > > It's an opt-in attribute that defines a whitelist of types something can own. > For example: > > @owns(TypeA, TypeB) struct TypeC { ... } > > I wrote this a few months ago, but we weren't accepting additive proposals. > Now we're explicitly looking for something like this: > > Memory ownership model: Adding an (opt-in) Cyclone/Rust inspired memory > ownership model to Swift is highly desired by systems programmers and folks > who want predictable and deterministic performance (for example, in real time > audio processing code). More pertinent to the goals of Swift 4, this feature > is important because it fundamentally shapes the ABI. It informs code > generation for “inout", how low-level “addressors” work in the ABI, impacts > the Swift runtime, and will have a significant impact on the type system and > name mangling. > > - Chris > <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160725/025676.html> > > ---- > > Here's a link to the version of the proposal > <https://github.com/therealbnut/swift-evolution/commit/6ab167825d802c7826804e1957eb515d3009743a> > when I sent this email. > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
