[swift-evolution] Equatable auto-write func == Proposal

Hi guys, It would be awesome if with this evolution, we could also auto-write equality operators for enum with equatable payloads. Today, considering this enum enum SimpleEnum { case case1 case case2 } the condition SimpleEnum.case1 == SimpleEnum.case1 compiles and return true. But if

Re: [swift-evolution] Should closures support inout parameters?

> On Sep 18, 2016, at 8:17 AM, Dave Abrahams via swift-evolution > wrote: > > > on Fri Sep 16 2016, Braeden Profile > wrote: > >> I was writing some code that would allow transformations of values as

Re: [swift-evolution] Should closures support inout parameters?

Good :), will it get put with the next Swift revision then? Sent from my iPhone > On 19 Sep 2016, at 08:37, Chris Lattner via swift-evolution > wrote: > > >> On Sep 18, 2016, at 8:17 AM, Dave Abrahams via swift-evolution >> wrote: >>

Re: [swift-evolution] Unicode identifiers & operators

on Sun Sep 18 2016, Xiaodi Wu wrote: > 2d) Confusables: I think the last time we had this discussion, it was > apparent that it'd be difficult to decide which confusables to allow or > disallow after some of the low-hanging fruit is taken care of by Unicode >

Re: [swift-evolution] Mark protocol methods with their protocol

> On Sep 19, 2016, at 12:10 PM, Vladimir.S via swift-evolution > wrote: > > On 17.09.2016 6:32, Xiaodi Wu via swift-evolution wrote: >> >> Let me give a concrete example of how retroactively modeling is used. > > Karl is suggesting interesting but complex and IMO

Re: [swift-evolution] Mark protocol methods with their protocol

If Swift 4 will make it impossible to tackle this again, I do not think discussing this can be avoided for Swift 3.1... I am afraid we are rushing into Swift 4 a bit too quickly, but perhaps it is just silly old me :). Sent from my iPhone > On 19 Sep 2016, at 19:18, Charles Srstka via

Re: [swift-evolution] [swift-dev] Rebinding UnsafePointer makes it mutable

> On Sep 19, 2016, at 1:24 AM, Martin R via swift-dev > wrote: > > I noticed that both UnsafePointer and UnsafeMutablePointer have the identical > method > >public func withMemoryRebound(to: T.Type, capacity count: Int, > _ body: (UnsafeMutablePointer)

Re: [swift-evolution] generic associatedtype?

If you have to compromise that much, it makes for a very compelling case to go for C++ wrapped in Objective-C(++) as far as that section of the code is concerned and call it from Swift using the already provided bridging support. I do not think anyone will question the purity of our bodily

Re: [swift-evolution] Mark protocol methods with their protocol

+1 Sent from my iPhone > On 19 Sep 2016, at 18:10, Vladimir.S via swift-evolution > wrote: > >> On 17.09.2016 6:32, Xiaodi Wu via swift-evolution wrote: >> >> Let me give a concrete example of how retroactively modeling is used. > > Karl is suggesting interesting

Re: [swift-evolution] [swift-users] Problem with COW optimization

> On Sep 19, 2016, at 3:18 AM, Adrian Zubarev via swift-evolution > wrote: > > I think I just found a solution to my problem: > > /// - Parameter child: The new `child` to add to the `children` array. > public mutating func add(_ child: Element) { > >let

Re: [swift-evolution] [swift-users] Problem with COW optimization

Hello Dave, thank you for trying to help me. I’ll try to explain the issue with some more details. First here is some code: extension XML { public struct Element { // public for testing public var reference: Reference public var name: String { return

Re: [swift-evolution] Mark protocol methods with their protocol

I definitely think Vladimir's suggestion is a great starting point, IMO. However, I think it could be improved in one key respect where previous proposals using `override` are superior. Namely, the proposed `implement` keyword adds no additional safety when a type implements a protocol

Re: [swift-evolution] Mark protocol methods with their protocol

I don't think "override" is a good idea. It's not overriding. Protocol is not Class. Xiaodi Wu via swift-evolution 于2016年9月20日 周二08:04写道： > I definitely think Vladimir's suggestion is a great starting point, IMO. > > However, I think it could be improved in one key

Re: [swift-evolution] [swift-users] Problem with COW optimization

or could the problem be flip on its head and implemented with a normal reference type, dealing with threading issues instead of having to optimise CoW and still perhaps being open to spikes in memory bandwidth at the wrong time when the copy is actually performed? Sent from my iPhone > On 19

Re: [swift-evolution] Mark protocol methods with their protocol

On Mon, Sep 19, 2016 at 7:15 PM, Boris Wang wrote: > I don't think "override" is a good idea. It's not overriding. > > Protocol is not Class. > I think you make a good point. It seems like people have generally written about "overriding" default implementations, but that