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

> 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] A case for postponing ABI stability

> On Jan 27, 2017, at 2:08 PM, Freak Show via swift-evolution > wrote: > > Maybe so - but IB M > solved this very problem along with release to release binary compatibility > for C++ and a number of other languages twenty years ago with the System > Object Model (SOM). Yeah and Microsoft’s C

Re: [swift-evolution] @NSCopying currently does not affect initializers

I agree that there is an issue here. While I understand that the initialiser avoids the full setter for direct access, I would expect the attribute to mean that the substituted direct access still applied the attribute you marked the API with. I would consider the fact that it doesn't work as a

Re: [swift-evolution] @NSCopying currently does not affect initializers

Yep, I also admit the design of forbidding calling a setter before full class initialization is reasonable and what's really annoying is the inconsistency. However, making @NSCopying attribute not subjects to the fact that setters would not be invoked in initializers perhaps is viable too. In the

Re: [swift-evolution] Checking in; more thoughts on arrays and variadic generics

> On Jan 27, 2017, at 4:55 PM, Karl Wagner wrote: > > >> On 27 Jan 2017, at 22:25, Slava Pestov > > wrote: >> >> >>> On Jan 27, 2017, at 11:44 AM, Karl Wagner via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> >>> So, 2 quick points: >>> >>> 1)

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

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] @NSCopying currently does not affect initializers

> Le 28 janv. 2017 à 05:34, Torin Kwok via swift-evolution > a écrit : > > Hello guys, > > Note: This issue has been originally presented in swift-users mailling list > . > And then I post it again here at the su