SE-1084 (B): buffer pointer partial initialization API

Hi guys, after passing SE 184 (A)
<https://github.com/apple/swift-evolution/blob/master/proposals/0184-unsafe-pointers-add-missing.md&gt;,
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
<https://github.com/apple/swift-evolution/blob/master/proposals/0184-unsafe-pointers-add-missing.md&gt;,
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])

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
<https://gist.github.com/kelvin13/0860334278aeab5c1cbaefbefb050268&gt; 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.

Hi guys, after passing SE 184 (A)
<https://github.com/apple/swift-evolution/blob/master/proposals/0184-unsafe-pointers-add-missing.md&gt;,
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
<https://github.com/apple/swift-evolution/blob/master/proposals/0184-unsafe-pointers-add-missing.md&gt;,
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[..<zero])

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 <https://gist.github.com/kelvin13/0860334278aeab5c1cbaefbefb050268&gt;
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.

···

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

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

Hi guys, after passing SE 184 (A)
<https://github.com/apple/swift-evolution/blob/master/proposals/0184-unsafe-pointers-add-missing.md&gt;,
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
<https://github.com/apple/swift-evolution/blob/master/proposals/0184-unsafe-pointers-add-missing.md&gt;,
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[..<zero])

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 <https://gist.github.com/kelvin13/0860334278aeab5c1cbaefbefb050268&gt;
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.

···

On Tue, Oct 10, 2017 at 1:00 AM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:

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

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

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

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 <xiaodi.wu@gmail.com> 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[..<zero])

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

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..<x.endIndex].foo()

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..<x.endIndex].foo() more implies “this will definitively replace the entire range from i to the end”?

(with x[i…].foo() living in an unpleasant grey-area)

···

On Oct 11, 2017, at 1:15 PM, Kelvin Ma via swift-evolution <swift-evolution@swift.org> wrote:

there is no way to allow one-sided subscripting, but disallow two-sided subscripting for the memory API

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.brackettrozinsky@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 <xiaodi.wu@gmail.com> 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[..<zero])
>
> 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

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 <kelvin13ma@gmail.com> 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.brackettrozinsky@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 <xiaodi.wu@gmail.com> >>> 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[..<zero])
>
> 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

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 <xiaodi.wu@gmail.com> 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[..<zero])
>
> 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

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..<x.endIndex].foo()

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..<x.endIndex].foo() more implies “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.

···

On Oct 11, 2017, at 3:42 PM, Ben Cohen <ben_cohen@apple.com> wrote:

On Oct 11, 2017, at 1:15 PM, Kelvin Ma via swift-evolution <swift-evolution@swift.org> wrote:

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.

I mean,,, you can,,, but that’s kind of weird

···

On Wed, Oct 11, 2017 at 6:06 PM, Nevin Brackett-Rozinsky < nevin.brackettrozinsky@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.brackettrozinsky@gmail.com> wrote:

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

Nevin

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

···

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

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.brackettrozinsky@gmail.com > <javascript:_e(%7B%7D,'cvml','nevin.brackettrozinsky@gmail.com');>> wrote:

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

Nevin

That's exactly how the [...] notation is implemented in the stdlib. Toni Suter wrote a great article about it: Unbounded Ranges in Swift 4 - Toni Suter

···

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 <nevin.brackettrozinsky@gmail.com <mailto:nevin.brackettrozinsky@gmail.com>> wrote:
On Wednesday, October 11, 2017, Kelvin Ma via swift-evolution <swift-evolution@swift.org <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

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 <ole@oleb.net> 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 <nevin. > brackettrozinsky@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/