Re: [swift-dev] copy-on-write proposal

> On Oct 20, 2016, at 10:11 AM, Andrew Trick wrote: > > >> On Oct 20, 2016, at 8:41 AM, Erik Eckstein > > wrote: >> >>> To clarify: I proposed an alternate approach in which the @sil_cow >>> reference is only mutable during the Array’s @inout scope—to be >>> autom

Re: [swift-dev] copy-on-write proposal

> On Oct 20, 2016, at 8:41 AM, Erik Eckstein wrote: > >> To clarify: I proposed an alternate approach in which the @sil_cow reference >> is only mutable during the Array’s @inout scope—to be automatically enforced >> by the compiler once @inout scopes are enforced. But the text in question is

Re: [swift-dev] copy-on-write proposal

> On Oct 20, 2016, at 8:51 AM, Dave Abrahams wrote: > > We might want to leave some room in the design for a shared atomic cache > reference to live in the buffer, FWIW. It would have to be mutable even when > the buffer was multiply-referenced Should be no problem with an attribute on that

Re: [swift-dev] copy-on-write proposal

We might want to leave some room in the design for a shared atomic cache reference to live in the buffer, FWIW. It would have to be mutable even when the buffer was multiply-referenced Sent from my moss-covered three-handled family gradunza > On Oct 20, 2016, at 8:41 AM, Erik Eckstein wrote:

Re: [swift-dev] copy-on-write proposal

> On Oct 19, 2016, at 6:36 PM, Andrew Trick via swift-dev > wrote: > >> >> On Oct 19, 2016, at 10:13 AM, Dave Abrahams via swift-dev >> mailto:swift-dev@swift.org>> wrote: >> >> >> on Tue Oct 18 2016, Erik Eckstein > > wrote: >> On Oct 17, 2016, at 10:2

Re: [swift-dev] copy-on-write proposal

> On Oct 19, 2016, at 10:13 AM, Dave Abrahams via swift-dev > wrote: > > > on Tue Oct 18 2016, Erik Eckstein > wrote: > >>> On Oct 17, 2016, at 10:21 AM, Dave Abrahams wrote: >>> >>> >>> on Mon Oct 17 2016, Erik Eckstein wrote: >>> >> On Oct 16, 201

Re: [swift-dev] copy-on-write proposal

on Tue Oct 18 2016, Erik Eckstein wrote: >> On Oct 17, 2016, at 10:21 AM, Dave Abrahams wrote: >> >> >> on Mon Oct 17 2016, Erik Eckstein wrote: >> > >>> On Oct 16, 2016, at 2:05 PM, Dave Abrahams via swift-dev >>> wrote: >>> on Thu Oct 13 2016, Joe Groff >>>

Re: [swift-dev] copy-on-write proposal

> On Oct 17, 2016, at 10:21 AM, Dave Abrahams wrote: > > > on Mon Oct 17 2016, Erik Eckstein wrote: > >> On Oct 16, 2016, at 2:05 PM, Dave Abrahams via swift-dev >> wrote: >> >>> on Thu Oct 13 2016, Joe Groff >> > wrote: >>> > On Oct 11, 2016, at 4:48 P

Re: [swift-dev] copy-on-write proposal

on Mon Oct 17 2016, Erik Eckstein wrote: > On Oct 16, 2016, at 2:05 PM, Dave Abrahams via swift-dev > wrote: > >> on Thu Oct 13 2016, Joe Groff > > wrote: >> On Oct 11, 2016, at 4:48 PM, Erik Eckstein via swift-dev wrote: This is a propos

Re: [swift-dev] copy-on-write proposal

On Oct 16, 2016, at 2:05 PM, Dave Abrahams via swift-dev wrote: > on Thu Oct 13 2016, Joe Groff > wrote: > >>> On Oct 11, 2016, at 4:48 PM, Erik Eckstein via swift-dev >>> wrote: >>> >>> This is a proposal for representing copy-on-write buffers in >>> SIL.

Re: [swift-dev] copy-on-write proposal

on Thu Oct 13 2016, Joe Groff wrote: >> On Oct 11, 2016, at 4:48 PM, Erik Eckstein via swift-dev >> wrote: >> >> This is a proposal for representing copy-on-write buffers in >> SIL. Actually it’s still a draft for a proposal. It also heavily >> depends on how we move forward with SIL ownershi

Re: [swift-dev] copy-on-write proposal

on Tue Oct 11 2016, Erik Eckstein wrote: > This is a proposal for representing copy-on-write buffers in > SIL. Actually it’s still a draft for a proposal. It also heavily > depends on how we move forward with SIL ownership. > > :orphan: > > .. highlight:: sil > >

Re: [swift-dev] copy-on-write proposal

> On Oct 13, 2016, at 10:36 AM, Joe Groff wrote: > > >> On Oct 11, 2016, at 4:48 PM, Erik Eckstein via swift-dev >> wrote: >> >> This is a proposal for representing copy-on-write buffers in SIL. Actually >> it’s still a draft for a proposal. It also heavily depends on how we move >> forwar

Re: [swift-dev] copy-on-write proposal

> On Oct 11, 2016, at 4:48 PM, Erik Eckstein via swift-dev > wrote: > > This is a proposal for representing copy-on-write buffers in SIL. Actually > it’s still a draft for a proposal. It also heavily depends on how we move > forward with SIL ownership. > > If you have any comments, please le

Re: [swift-dev] copy-on-write proposal

> On Oct 12, 2016, at 11:19 AM, Alexis via swift-dev > wrote: > > I’m having trouble figuring something out: is all of this contingent on all > of the relevant operations being completely inlined into a single function at > the SIL level? Could failing to inline a standard library function le

Re: [swift-dev] copy-on-write proposal

> On Oct 12, 2016, at 11:19 AM, Alexis wrote: > > I’m having trouble figuring something out: is all of this contingent on all > of the relevant operations being completely inlined into a single function at > the SIL level? Could failing to inline a standard library function lead to > performa

Re: [swift-dev] copy-on-write proposal

I’m having trouble figuring something out: is all of this contingent on all of the relevant operations being completely inlined into a single function at the SIL level? Could failing to inline a standard library function lead to performance cliffs? I understand this is generally true of inlining

Re: [swift-dev] copy-on-write proposal

Thanks for the feedback! Here is an updated version of the proposal: https://github.com/eeckstein/swift/blob/cow-proposal/docs/proposals/CopyOnWrite.rst (you can look at the history to see the changes compared

Re: [swift-dev] copy-on-write proposal

> > > :orphan: > > .. highlight:: sil > > === > Copy-On-Write Representation in SIL > === > > .. contents:: > > Overview > > > This document proposes: > > - An ownership attribute to define copy-on-write (COW) buff

[swift-dev] copy-on-write proposal

This is a proposal for representing copy-on-write buffers in SIL. Actually it’s still a draft for a proposal. It also heavily depends on how we move forward with SIL ownership. CopyOnWrite.rst Description: Binary data If you have any comments, please let me know. Erik __