Re: [swift-evolution] Shouldn't ".withUnsafeBufferPointer" and ".withUnsafeMutableBufferPointer" be parts of protocols?

2017-02-05 Thread Daryle Walker via swift-evolution
> On Jan 27, 2017, at 7:36 PM, Zach Waldowski via swift-evolution > wrote: > > I like the sound of it so far, but my first major thought is that isn't it > modeling a "has-a" relationship instead of an "is-a"? The buffer methods > indicate that the data type *can* be represented as a buffer f

Re: [swift-evolution] Shouldn't ".withUnsafeBufferPointer" and ".withUnsafeMutableBufferPointer" be parts of protocols?

2017-02-05 Thread Daryle Walker via swift-evolution
> On Jan 27, 2017, at 7:24 PM, Karl Wagner wrote: > > There is a bug tracking this: > > https://bugs.swift.org/browse/SR-3631 Saw it. Joined Swift-JIRA. Posted my comments. — Daryle Walker Mac, Internet, and Video Game Junkie darylew AT mac DOT com _

Re: [swift-evolution] Shouldn't ".withUnsafeBufferPointer" and ".withUnsafeMutableBufferPointer" be parts of protocols?

2017-01-29 Thread Dave Abrahams via swift-evolution
on Sun Jan 29 2017, Dave Abrahams wrote: > on Sat Jan 28 2017, Brent Royal-Gordon wrote: > >>> On Jan 28, 2017, at 11:48 AM, Dave Abrahams via swift-evolution >>> > wrote: >>> >>> The way to handle Deque is to add this requirement to Collection when >>> we get the language features to expres

Re: [swift-evolution] Shouldn't ".withUnsafeBufferPointer" and ".withUnsafeMutableBufferPointer" be parts of protocols?

2017-01-29 Thread Dave Abrahams via swift-evolution
on Sat Jan 28 2017, Brent Royal-Gordon wrote: >> On Jan 28, 2017, at 11:48 AM, Dave Abrahams via swift-evolution >> wrote: >> >> The way to handle Deque is to add this requirement to Collection when >> we get the language features to express it: >> > >> protocol Collection { >> >>assoc

Re: [swift-evolution] Shouldn't ".withUnsafeBufferPointer" and ".withUnsafeMutableBufferPointer" be parts of protocols?

2017-01-28 Thread Brent Royal-Gordon via swift-evolution
> On Jan 28, 2017, at 11:48 AM, Dave Abrahams via swift-evolution > wrote: > > The way to handle Deque is to add this requirement to Collection when > we get the language features to express it: > > protocol Collection { > >associatedtype Segments : Collection >where Segments.Element

Re: [swift-evolution] Shouldn't ".withUnsafeBufferPointer" and ".withUnsafeMutableBufferPointer" be parts of protocols?

2017-01-28 Thread Dave Abrahams via swift-evolution
on Fri Jan 27 2017, Zach Waldowski wrote: > I like the sound of it so far, but my first major thought is that isn't > it modeling a "has-a" relationship instead of an "is-a"? The buffer > methods indicate that the data type *can* be represented as a buffer for > the duration of the method call,

Re: [swift-evolution] Shouldn't ".withUnsafeBufferPointer" and ".withUnsafeMutableBufferPointer" be parts of protocols?

2017-01-27 Thread Zach Waldowski via swift-evolution
I like the sound of it so far, but my first major thought is that isn't it modeling a "has-a" relationship instead of an "is-a"? The buffer methods indicate that the data type *can* be represented as a buffer for the duration of the method call, but may not necessarily be before or after. Such a se

Re: [swift-evolution] Shouldn't ".withUnsafeBufferPointer" and ".withUnsafeMutableBufferPointer" be parts of protocols?

2017-01-27 Thread Karl Wagner via swift-evolution
There is a bug tracking this: https://bugs.swift.org/browse/SR-3631 ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] Shouldn't ".withUnsafeBufferPointer" and ".withUnsafeMutableBufferPointer" be parts of protocols?

2017-01-27 Thread Daryle Walker via swift-evolution
I was perusing the library for array ideas, and noticed that several types had methods in common, but without a grouping protocol. Shouldn’t that be fixed? (Oh, if multiple protocols have an associated-type with the same name, is that a problem? Is it a problem if they resolve differently for ea