Re: [swift-evolution] SE-1084 (B): buffer pointer partial initialization API

[Kelvin Ma via swift-evolution]

Did not know you could do that. Still doesn’t change the fundamental
problems with that syntax though. I think that we could enforce a
precondition that overrunning the left hand slice is not allowed, but idk
if subscript notation is worth all that trouble.

On Thu, Oct 12, 2017 at 3:36 AM, Ole Begemann  wrote:

>
> On 12. Oct 2017, at 01:17, Kelvin Ma via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> On Wed, Oct 11, 2017 at 6:06 PM, Nevin Brackett-Rozinsky  brackettrozin...@gmail.com> wrote:
>
>> On Wednesday, October 11, 2017, Kelvin Ma via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>> Yes, a 0-ary operator like that would have to be hard baked into the
>>> language itself.
>>>
>>
>> Actually, you can just make a subscript which takes a function as an
>> argument, and call it by passing in the ellipsis operator.
>>
>
> I mean,,, you can,,, but that’s kind of weird
>
>
> That's exactly how the [...] notation is implemented in the stdlib. Toni
> Suter wrote a great article about it: https://tonisuter.com/
> blog/2017/08/unbounded-ranges-swift-4/
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] SE-1084 (B): buffer pointer partial initialization API

[Ole Begemann via swift-evolution]

> On 12. Oct 2017, at 01:17, Kelvin Ma via swift-evolution 
>  wrote:
> 
> On Wed, Oct 11, 2017 at 6:06 PM, Nevin Brackett-Rozinsky 
> mailto:nevin.brackettrozin...@gmail.com>> 
> wrote:
> On Wednesday, October 11, 2017, Kelvin Ma via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> Yes, a 0-ary operator like that would have to be hard baked into the language 
> itself.
> 
> Actually, you can just make a subscript which takes a function as an 
> argument, and call it by passing in the ellipsis operator.
> 
> I mean,,, you can,,, but that’s kind of weird

That's exactly how the [...] notation is implemented in the stdlib. Toni Suter 
wrote a great article about it: 
https://tonisuter.com/blog/2017/08/unbounded-ranges-swift-4/ 


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] SE-1084 (B): buffer pointer partial initialization API

[Kelvin Ma via swift-evolution]

On Wed, Oct 11, 2017 at 6:06 PM, Nevin Brackett-Rozinsky <
nevin.brackettrozin...@gmail.com> wrote:

> On Wednesday, October 11, 2017, Kelvin Ma via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> Yes, a 0-ary operator like that would have to be hard baked into the
>> language itself.
>>
>
> Actually, you can just make a subscript which takes a function as an
> argument, and call it by passing in the ellipsis operator.
>
> Nevin
>
>
>
>  Of course, the subscript notation has much more serious problems, there
>> is no way to allow one-sided subscripting, but disallow two-sided
>> subscripting for the memory API, while still allowing two-sided
>> subscripting for ordinary slicing operations. This is why I still think
>> at:from: is the much better syntax.
>>
>> On Wed, Oct 11, 2017 at 3:01 PM, Nevin Brackett-Rozinsky <
>> nevin.brackettrozin...@gmail.com> wrote:
>>
>>> I believe Kelvin was asking about the usage of ellipsis *by itself*, as
>>> in Xiaodi’s example, “newBuffer[...]”.
>>>
>>> Nevin
>>>
>>
I mean,,, you can,,, but that’s kind of weird
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] SE-1084 (B): buffer pointer partial initialization API

[Nevin Brackett-Rozinsky via swift-evolution]

On Wednesday, October 11, 2017, Kelvin Ma via swift-evolution <
swift-evolution@swift.org> wrote:

> Yes, a 0-ary operator like that would have to be hard baked into the
> language itself.
>

Actually, you can just make a subscript which takes a function as an
argument, and call it by passing in the ellipsis operator.

Nevin


 Of course, the subscript notation has much more serious problems, there is
> no way to allow one-sided subscripting, but disallow two-sided subscripting
> for the memory API, while still allowing two-sided subscripting for
> ordinary slicing operations. This is why I still think at:from: is the
> much better syntax.
>
> On Wed, Oct 11, 2017 at 3:01 PM, Nevin Brackett-Rozinsky <
> nevin.brackettrozin...@gmail.com
> > wrote:
>
>> I believe Kelvin was asking about the usage of ellipsis *by itself*, as
>> in Xiaodi’s example, “newBuffer[...]”.
>>
>> Nevin
>>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] SE-1084 (B): buffer pointer partial initialization API

[Taylor Swift via swift-evolution]

> On Oct 11, 2017, at 3:42 PM, Ben Cohen  wrote:
> 
> 
> 
>> On Oct 11, 2017, at 1:15 PM, Kelvin Ma via swift-evolution 
>>  wrote:
>> 
>> there is no way to allow one-sided subscripting, but disallow two-sided 
>> subscripting for the memory API
> 
> One-sided subscripting is just shorthand for “from here to the end” (or from 
> the start to/through here). If a one-sided subscript is just shorthand for a 
> two-sided subscript there cannot be a circumstance where one is allowed but 
> not the other. This kind of rule should be consistent throughout the library.

You are entirely correct which is why i’m not comfortable with this syntax.

> 
> If a “from:” argument, similarly, means “write from here up to the end” (and 
> no further, it’s reasonable to assume, if we’re talking about collections) 
> then x.foo(from: i) is similar to saying x[i…].foo(), which in turn is 
> similar to saying x[5.. 

from: in the buffer pointer API refers to the source buffer which contains a 
`count` property. it’s analogous to the count: argument in the plain pointer 
API.

> Do you feel like a “from:” argument avoids implying there is a specific end 
> point to the operation? That is, it might not get as far as x.endIndex if it 
> runs out of stuff to write. Whereas x[i.. “this will definitively replace the entire range from i to the end”?
> 
> (with x[i…].foo() living in an unpleasant grey-area)
> 

pretty much. We only want one "count" number floating around here so the 
behavior is easy to think about, and since the source buffer already contains a 
count we want the syntax to avoid implying a second quantity that might 
contradict `source.count` as much as possible.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] SE-1084 (B): buffer pointer partial initialization API

[Ben Cohen via swift-evolution]

> On Oct 11, 2017, at 1:15 PM, Kelvin Ma via swift-evolution 
>  wrote:
> 
> there is no way to allow one-sided subscripting, but disallow two-sided 
> subscripting for the memory API

One-sided subscripting is just shorthand for “from here to the end” (or from 
the start to/through here). If a one-sided subscript is just shorthand for a 
two-sided subscript there cannot be a circumstance where one is allowed but not 
the other. This kind of rule should be consistent throughout the library.

If a “from:” argument, similarly, means “write from here up to the end” (and no 
further, it’s reasonable to assume, if we’re talking about collections) then 
x.foo(from: i) is similar to saying x[i…].foo(), which in turn is similar to 
saying x[5..___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] SE-1084 (B): buffer pointer partial initialization API

[Kelvin Ma via swift-evolution]

I should also add I think I remember the String people trying to add
collection[] empty subscripts to the language but I don’t remember that
ever going through.

On Wed, Oct 11, 2017 at 3:15 PM, Kelvin Ma  wrote:

> Yes, a 0-ary operator like that would have to be hard baked into the
> language itself. Of course, the subscript notation has much more serious
> problems, there is no way to allow one-sided subscripting, but disallow
> two-sided subscripting for the memory API, while still allowing two-sided
> subscripting for ordinary slicing operations. This is why I still think
> at:from: is the much better syntax.
>
> On Wed, Oct 11, 2017 at 3:01 PM, Nevin Brackett-Rozinsky <
> nevin.brackettrozin...@gmail.com> wrote:
>
>> I believe Kelvin was asking about the usage of ellipsis *by itself*, as
>> in Xiaodi’s example, “newBuffer[...]”.
>>
>> Nevin
>>
>>
>> On Wed, Oct 11, 2017 at 2:42 PM, Anders Ha via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>> ICYMI, SE-0172 was the proposal of one sided range and it has been
>>> implemented as part of 4.0.
>>>
>>> https://github.com/apple/swift-evolution/blob/master/proposa
>>> ls/0172-one-sided-ranges.md
>>>
>>>
>>> Regards
>>> Anders
>>>
>>> > On 11 Oct 2017, at 4:43 AM, Kelvin Ma via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>> >
>>> >
>>> >
>>> > On Tue, Oct 10, 2017 at 1:00 AM, Xiaodi Wu 
>>> wrote:
>>> > On Mon, Oct 9, 2017 at 19:47 Kelvin Ma via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>> > Hi guys, after passing SE 184 (A), I want to get some community
>>> feedback on the next phase of our Swift pointer overhaul which is a partial
>>> initialization/deinitialization API for UnsafeMutableBufferPointer and
>>> UnsafeMutableRawBufferPointer.
>>> >
>>> > You can read about the originally proposed API in the original SE 184
>>> document, basically we use an at:from: system for binary memory state
>>> operations where the at: argument supplies the start position in the
>>> destination buffer, and the from: source argument supplies the number of
>>> elements to copy/move into the destination.
>>> >
>>> > newBuffer.moveInitialize(at: 0, from: self.buffer[self.zero... ])
>>> > newBuffer.moveInitialize(at: self.zero, from: self.buffer[0 ..<
>>> self.zero])
>>> >
>>> > Some other proposed APIs include using subscript notation, and writing
>>> a special buffer slice type and a corresponding protocol to handle this.
>>> >
>>> > newBuffer[0...].moveInitialize(from:
>>> self.buffer[self.zero...   ])
>>> > newBuffer[self.zero ... self.zero << 1].moveInitialize(from:
>>> self.buffer[0 ..< self.zero])
>>> >
>>> > Fully embracing slice notation and SwiftLint style, this could be:
>>> >
>>> > newBuffer[...].moveInitialize(from: buffer[zero...])
>>> > newBuffer[zero...].moveInitialize(from: buffer[..>> >
>>> > Is the solo ellipsis operator even valid Swift syntax? And I agree
>>> this would look nice, but as others have mentioned, Swift has the
>>> convention that the one-sided slice operators are equivalent to start ...
>>> endIndex and startIndex ... end. And that seems to strongly suggest that
>>> the method would initialize the entire range which is not what we want to
>>> communicate.
>>> >
>>> >
>>> > A hypothetical comparison of this API, the at:from: API, and the
>>> existing plain pointer API can be found in this basic Swift queue
>>> implementation here if anyone wants to see how this would look in “real”
>>> code. I’m interested in seeing which syntax and which API is preferred as
>>> well as what people would like to do with an expanded Swift buffer pointer
>>> toolbox.
>>> >
>>> > Would you mind rewriting these examples in a more common Swift style
>>> (for instance, SwiftLint/GitHub style)? Everyone is entitled to write code
>>> how they please, but it’s much easier to compare how things “look” when the
>>> overall formatting is more familiar.
>>> >
>>> > I mean the purpose of the example is to compare the call sites of the
>>> actual buffer methods. ignoring the function signatures and instead getting
>>> distracted by brace placement seems like the kind of bikeshedding we should
>>> be discouraging lol.
>>> >
>>> >
>>> >
>>> > ___
>>> > swift-evolution mailing list
>>> > swift-evolution@swift.org
>>> > https://lists.swift.org/mailman/listinfo/swift-evolution
>>> >
>>> > ___
>>> > swift-evolution mailing list
>>> > swift-evolution@swift.org
>>> > https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>
>>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] SE-1084 (B): buffer pointer partial initialization API

[Kelvin Ma via swift-evolution]

Yes, a 0-ary operator like that would have to be hard baked into the
language itself. Of course, the subscript notation has much more serious
problems, there is no way to allow one-sided subscripting, but disallow
two-sided subscripting for the memory API, while still allowing two-sided
subscripting for ordinary slicing operations. This is why I still think
at:from: is the much better syntax.

On Wed, Oct 11, 2017 at 3:01 PM, Nevin Brackett-Rozinsky <
nevin.brackettrozin...@gmail.com> wrote:

> I believe Kelvin was asking about the usage of ellipsis *by itself*, as in
> Xiaodi’s example, “newBuffer[...]”.
>
> Nevin
>
>
> On Wed, Oct 11, 2017 at 2:42 PM, Anders Ha via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> ICYMI, SE-0172 was the proposal of one sided range and it has been
>> implemented as part of 4.0.
>>
>> https://github.com/apple/swift-evolution/blob/master/proposa
>> ls/0172-one-sided-ranges.md
>>
>>
>> Regards
>> Anders
>>
>> > On 11 Oct 2017, at 4:43 AM, Kelvin Ma via swift-evolution <
>> swift-evolution@swift.org> wrote:
>> >
>> >
>> >
>> > On Tue, Oct 10, 2017 at 1:00 AM, Xiaodi Wu  wrote:
>> > On Mon, Oct 9, 2017 at 19:47 Kelvin Ma via swift-evolution <
>> swift-evolution@swift.org> wrote:
>> > Hi guys, after passing SE 184 (A), I want to get some community
>> feedback on the next phase of our Swift pointer overhaul which is a partial
>> initialization/deinitialization API for UnsafeMutableBufferPointer and
>> UnsafeMutableRawBufferPointer.
>> >
>> > You can read about the originally proposed API in the original SE 184
>> document, basically we use an at:from: system for binary memory state
>> operations where the at: argument supplies the start position in the
>> destination buffer, and the from: source argument supplies the number of
>> elements to copy/move into the destination.
>> >
>> > newBuffer.moveInitialize(at: 0, from: self.buffer[self.zero... ])
>> > newBuffer.moveInitialize(at: self.zero, from: self.buffer[0 ..<
>> self.zero])
>> >
>> > Some other proposed APIs include using subscript notation, and writing
>> a special buffer slice type and a corresponding protocol to handle this.
>> >
>> > newBuffer[0...].moveInitialize(from:
>> self.buffer[self.zero...   ])
>> > newBuffer[self.zero ... self.zero << 1].moveInitialize(from:
>> self.buffer[0 ..< self.zero])
>> >
>> > Fully embracing slice notation and SwiftLint style, this could be:
>> >
>> > newBuffer[...].moveInitialize(from: buffer[zero...])
>> > newBuffer[zero...].moveInitialize(from: buffer[..> >
>> > Is the solo ellipsis operator even valid Swift syntax? And I agree this
>> would look nice, but as others have mentioned, Swift has the convention
>> that the one-sided slice operators are equivalent to start ... endIndex and
>> startIndex ... end. And that seems to strongly suggest that the method
>> would initialize the entire range which is not what we want to communicate.
>> >
>> >
>> > A hypothetical comparison of this API, the at:from: API, and the
>> existing plain pointer API can be found in this basic Swift queue
>> implementation here if anyone wants to see how this would look in “real”
>> code. I’m interested in seeing which syntax and which API is preferred as
>> well as what people would like to do with an expanded Swift buffer pointer
>> toolbox.
>> >
>> > Would you mind rewriting these examples in a more common Swift style
>> (for instance, SwiftLint/GitHub style)? Everyone is entitled to write code
>> how they please, but it’s much easier to compare how things “look” when the
>> overall formatting is more familiar.
>> >
>> > I mean the purpose of the example is to compare the call sites of the
>> actual buffer methods. ignoring the function signatures and instead getting
>> distracted by brace placement seems like the kind of bikeshedding we should
>> be discouraging lol.
>> >
>> >
>> >
>> > ___
>> > swift-evolution mailing list
>> > swift-evolution@swift.org
>> > https://lists.swift.org/mailman/listinfo/swift-evolution
>> >
>> > ___
>> > swift-evolution mailing list
>> > swift-evolution@swift.org
>> > https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] SE-1084 (B): buffer pointer partial initialization API

[Nevin Brackett-Rozinsky via swift-evolution]

I believe Kelvin was asking about the usage of ellipsis *by itself*, as in
Xiaodi’s example, “newBuffer[...]”.

Nevin


On Wed, Oct 11, 2017 at 2:42 PM, Anders Ha via swift-evolution <
swift-evolution@swift.org> wrote:

> ICYMI, SE-0172 was the proposal of one sided range and it has been
> implemented as part of 4.0.
>
> https://github.com/apple/swift-evolution/blob/master/
> proposals/0172-one-sided-ranges.md
>
>
> Regards
> Anders
>
> > On 11 Oct 2017, at 4:43 AM, Kelvin Ma via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> >
> >
> > On Tue, Oct 10, 2017 at 1:00 AM, Xiaodi Wu  wrote:
> > On Mon, Oct 9, 2017 at 19:47 Kelvin Ma via swift-evolution <
> swift-evolution@swift.org> wrote:
> > Hi guys, after passing SE 184 (A), I want to get some community feedback
> on the next phase of our Swift pointer overhaul which is a partial
> initialization/deinitialization API for UnsafeMutableBufferPointer and
> UnsafeMutableRawBufferPointer.
> >
> > You can read about the originally proposed API in the original SE 184
> document, basically we use an at:from: system for binary memory state
> operations where the at: argument supplies the start position in the
> destination buffer, and the from: source argument supplies the number of
> elements to copy/move into the destination.
> >
> > newBuffer.moveInitialize(at: 0, from: self.buffer[self.zero... ])
> > newBuffer.moveInitialize(at: self.zero, from: self.buffer[0 ..<
> self.zero])
> >
> > Some other proposed APIs include using subscript notation, and writing a
> special buffer slice type and a corresponding protocol to handle this.
> >
> > newBuffer[0...].moveInitialize(from:
> self.buffer[self.zero...   ])
> > newBuffer[self.zero ... self.zero << 1].moveInitialize(from:
> self.buffer[0 ..< self.zero])
> >
> > Fully embracing slice notation and SwiftLint style, this could be:
> >
> > newBuffer[...].moveInitialize(from: buffer[zero...])
> > newBuffer[zero...].moveInitialize(from: buffer[.. >
> > Is the solo ellipsis operator even valid Swift syntax? And I agree this
> would look nice, but as others have mentioned, Swift has the convention
> that the one-sided slice operators are equivalent to start ... endIndex and
> startIndex ... end. And that seems to strongly suggest that the method
> would initialize the entire range which is not what we want to communicate.
> >
> >
> > A hypothetical comparison of this API, the at:from: API, and the
> existing plain pointer API can be found in this basic Swift queue
> implementation here if anyone wants to see how this would look in “real”
> code. I’m interested in seeing which syntax and which API is preferred as
> well as what people would like to do with an expanded Swift buffer pointer
> toolbox.
> >
> > Would you mind rewriting these examples in a more common Swift style
> (for instance, SwiftLint/GitHub style)? Everyone is entitled to write code
> how they please, but it’s much easier to compare how things “look” when the
> overall formatting is more familiar.
> >
> > I mean the purpose of the example is to compare the call sites of the
> actual buffer methods. ignoring the function signatures and instead getting
> distracted by brace placement seems like the kind of bikeshedding we should
> be discouraging lol.
> >
> >
> >
> > ___
> > swift-evolution mailing list
> > swift-evolution@swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
> >
> > ___
> > swift-evolution mailing list
> > swift-evolution@swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] SE-1084 (B): buffer pointer partial initialization API

[Anders Ha via swift-evolution]

ICYMI, SE-0172 was the proposal of one sided range and it has been implemented 
as part of 4.0.

https://github.com/apple/swift-evolution/blob/master/proposals/0172-one-sided-ranges.md


Regards
Anders

> On 11 Oct 2017, at 4:43 AM, Kelvin Ma via swift-evolution 
>  wrote:
> 
> 
> 
> On Tue, Oct 10, 2017 at 1:00 AM, Xiaodi Wu  wrote:
> On Mon, Oct 9, 2017 at 19:47 Kelvin Ma via swift-evolution 
>  wrote:
> Hi guys, after passing SE 184 (A), I want to get some community feedback on 
> the next phase of our Swift pointer overhaul which is a partial 
> initialization/deinitialization API for UnsafeMutableBufferPointer and 
> UnsafeMutableRawBufferPointer. 
> 
> You can read about the originally proposed API in the original SE 184 
> document, basically we use an at:from: system for binary memory state 
> operations where the at: argument supplies the start position in the 
> destination buffer, and the from: source argument supplies the number of 
> elements to copy/move into the destination. 
> 
> newBuffer.moveInitialize(at: 0, from: self.buffer[self.zero... ])
> newBuffer.moveInitialize(at: self.zero, from: self.buffer[0 ..< self.zero])
> 
> Some other proposed APIs include using subscript notation, and writing a 
> special buffer slice type and a corresponding protocol to handle this. 
> 
> newBuffer[0...].moveInitialize(from: 
> self.buffer[self.zero...   ])
> newBuffer[self.zero ... self.zero << 1].moveInitialize(from: self.buffer[0 
> ..< self.zero])
> 
> Fully embracing slice notation and SwiftLint style, this could be:
> 
> newBuffer[...].moveInitialize(from: buffer[zero...])
> newBuffer[zero...].moveInitialize(from: buffer[.. 
> Is the solo ellipsis operator even valid Swift syntax? And I agree this would 
> look nice, but as others have mentioned, Swift has the convention that the 
> one-sided slice operators are equivalent to start ... endIndex and startIndex 
> ... end. And that seems to strongly suggest that the method would initialize 
> the entire range which is not what we want to communicate.
>  
> 
> A hypothetical comparison of this API, the at:from: API, and the existing 
> plain pointer API can be found in this basic Swift queue implementation here 
> if anyone wants to see how this would look in “real” code. I’m interested in 
> seeing which syntax and which API is preferred as well as what people would 
> like to do with an expanded Swift buffer pointer toolbox.
> 
> Would you mind rewriting these examples in a more common Swift style (for 
> instance, SwiftLint/GitHub style)? Everyone is entitled to write code how 
> they please, but it’s much easier to compare how things “look” when the 
> overall formatting is more familiar. 
> 
> I mean the purpose of the example is to compare the call sites of the actual 
> buffer methods. ignoring the function signatures and instead getting 
> distracted by brace placement seems like the kind of bikeshedding we should 
> be discouraging lol.
>  
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] SE-1084 (B): buffer pointer partial initialization API

[Kelvin Ma via swift-evolution]

On Tue, Oct 10, 2017 at 1:00 AM, Xiaodi Wu  wrote:

> On Mon, Oct 9, 2017 at 19:47 Kelvin Ma via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> Hi guys, after passing SE 184 (A)
>> ,
>> I want to get some community feedback on the next phase of our Swift
>> pointer overhaul which is a partial initialization/deinitialization API
>> for UnsafeMutableBufferPointer and UnsafeMutableRawBufferPointer.
>>
>> You can read about the originally proposed API in the original SE 184
>> document
>> ,
>> basically we use an at:from: system for binary memory state operations
>> where the at: argument supplies the start position in the destination
>> buffer, and the from: source argument supplies the number of elements to
>> copy/move into the destination.
>>
>> newBuffer.moveInitialize(at: 0, from: self.buffer[self.zero... ])
>> newBuffer.moveInitialize(at: self.zero, from: self.buffer[0 ..<
>> self.zero])
>>
>> Some other proposed APIs include using subscript notation, and writing a
>> special buffer slice type and a corresponding protocol to handle this.
>>
>> newBuffer[0...].moveInitialize(from:
>> self.buffer[self.zero...   ])
>> newBuffer[self.zero ... self.zero << 1].moveInitialize(from:
>> self.buffer[0 ..< self.zero])
>>
>
> Fully embracing slice notation and SwiftLint style, this could be:
>
> newBuffer[...].moveInitialize(from: buffer[zero...])
> newBuffer[zero...].moveInitialize(from: buffer[..

Is the solo ellipsis operator even valid Swift syntax? And I agree this
would look nice, but as others have mentioned, Swift has the convention
that the one-sided slice operators are equivalent to start ...
endIndex and startIndex
... end. And that seems to strongly suggest that the method would
initialize the entire range which is not what we want to communicate.


>
> A hypothetical comparison of this API, the at:from: API, and the existing
>> plain pointer API can be found in this basic Swift queue implementation
>> here 
>> if anyone wants to see how this would look in “real” code. I’m interested
>> in seeing which syntax and which API is preferred as well as what people
>> would like to do with an expanded Swift buffer pointer toolbox.
>>
>
> Would you mind rewriting these examples in a more common Swift style (for
> instance, SwiftLint/GitHub style)? Everyone is entitled to write code how
> they please, but it’s much easier to compare how things “look” when the
> overall formatting is more familiar.
>

I mean the purpose of the example is to compare the call sites of the
actual buffer methods. ignoring the function signatures and instead getting
distracted by brace placement seems like the kind of bikeshedding we should
be discouraging lol.


>
>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] SE-1084 (B): buffer pointer partial initialization API

[Xiaodi Wu via swift-evolution]

On Mon, Oct 9, 2017 at 19:47 Kelvin Ma via swift-evolution <
swift-evolution@swift.org> wrote:

> Hi guys, after passing SE 184 (A)
> ,
> I want to get some community feedback on the next phase of our Swift
> pointer overhaul which is a partial initialization/deinitialization API for
> UnsafeMutableBufferPointer and UnsafeMutableRawBufferPointer.
>
> You can read about the originally proposed API in the original SE 184
> document
> ,
> basically we use an at:from: system for binary memory state operations
> where the at: argument supplies the start position in the destination
> buffer, and the from: source argument supplies the number of elements to
> copy/move into the destination.
>
> newBuffer.moveInitialize(at: 0, from: self.buffer[self.zero... ])
> newBuffer.moveInitialize(at: self.zero, from: self.buffer[0 ..< self.zero])
>
> Some other proposed APIs include using subscript notation, and writing a
> special buffer slice type and a corresponding protocol to handle this.
>
> newBuffer[0...].moveInitialize(from:
> self.buffer[self.zero...   ])
> newBuffer[self.zero ... self.zero << 1].moveInitialize(from: self.buffer[0
> ..< self.zero])
>

Fully embracing slice notation and SwiftLint style, this could be:

newBuffer[...].moveInitialize(from: buffer[zero...])
newBuffer[zero...].moveInitialize(from: buffer[.. plain pointer API can be found in this basic Swift queue implementation
> here 
> if anyone wants to see how this would look in “real” code. I’m interested
> in seeing which syntax and which API is preferred as well as what people
> would like to do with an expanded Swift buffer pointer toolbox.
>

Would you mind rewriting these examples in a more common Swift style (for
instance, SwiftLint/GitHub style)? Everyone is entitled to write code how
they please, but it’s much easier to compare how things “look” when the
overall formatting is more familiar.


> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution