Re: [swift-users] Calling (Void) -> () with Void

I think the fix-it is hinting that you need a value of type Void, not literally Void itself. It's a bit confusing since () is both a type and a value, while Void is only a type since it's declared as a typealias. Typealiases aren't processed like macros are, it would seem. I think the convention

[swift-users] Calling (Void) -> () with Void

Hello, I’m having some odd results with closures that take Void as a parameter, and was wondering if this was expected behavior or a bug. Specifically, I have the following closure: > Welcome to Apple Swift version 4.0 (swiftlang-900.0.45.6 clang-900.0.26). > let foo: (Void) -> () = {} Trying

[swift-users] TWISt-shout Newsletter 2017-07-10

Hi All. Here is your TWISt-shout Newsletter for the week of 2017-07-03 to 2017-07-10 https://github.com/pepperdog/TWISt-shout/blob/master/2017/TWISt-shout-2017-07-10.md Enjoy! -Kenny

Re: [swift-users] is this a defect in equatable for swift tuples?

Since Array has .elementsEqual, another workaround (until conditional conformance) is: class Tree : Equatable { let rootData:Int let children:[(String, Tree)] init(rootData: Int, children: [(String, Tree)]) { self.rootData = rootData self.children = children }

Re: [swift-users] is this a defect in equatable for swift tuples?

> On 9. Jul 2017, at 21:20, David Baraff wrote: > > Nice: i hadn’t seen elementsEqual. > > (1) Why do you have to pass in “by: ==“ ? is not that the default There are two versions: One taking an explicit predicate, and another which requires sequences of Equatable

Re: [swift-users] is this a defect in equatable for swift tuples?

Nice: i hadn’t seen elementsEqual. (1) Why do you have to pass in “by: ==“ ? is not that the default (2) not a big deal, but if the sequence type’s length can be determined a priori (e.g. in the case of an Array, or perhaps a Collection if that has a count member, haven’t checked) does

Re: [swift-users] is this a defect in equatable for swift tuples?

> On 9. Jul 2017, at 21:00, Jens Persson via swift-users > wrote: > > Since Array has .elementsEqual, another workaround (until conditional > conformance) is: > > class Tree : Equatable { > let rootData:Int > let children:[(String, Tree)] > >

Re: [swift-users] is this a defect in equatable for swift tuples?

> On Jul 9, 2017, at 10:06, David Baraff via swift-users > wrote: > > >> On Jul 9, 2017, at 8:27 AM, Jens Persson wrote: >> >> (Also, note that your implementation of == uses lhs === rhs thus will only >> return true when lhs and rhs are the same

Re: [swift-users] is this a defect in equatable for swift tuples?

> On Jul 9, 2017, at 8:27 AM, Jens Persson wrote: > > (Also, note that your implementation of == uses lhs === rhs thus will only > return true when lhs and rhs are the same instance of SomeClass.) Of course — i threw that in just to make a simple example. Followup question:

Re: [swift-users] is this a defect in equatable for swift tuples?

(Also, note that your implementation of == uses lhs === rhs thus will only return true when lhs and rhs are the same instance of SomeClass.) /Jens On Sun, Jul 9, 2017 at 5:24 PM, Jens Persson wrote: > Making SomeClass conform to Equatable should fix it: > > class SomeClass :

Re: [swift-users] is this a defect in equatable for swift tuples?

> On Jul 9, 2017, at 8:16 AM, Adrian Zubarev > wrote: > > Easy: class SomeClass : Equatable { > > Doh!! thank you. > > > -- > Adrian Zubarev > Sent with Airmail > > Am 9. Juli 2017 um 17:11:14, David Baraff via swift-users > (swift-users@swift.org

Re: [swift-users] is this a defect in equatable for swift tuples?

Easy: class SomeClass : Equatable { --  Adrian Zubarev Sent with Airmail Am 9. Juli 2017 um 17:11:14, David Baraff via swift-users (swift-users@swift.org) schrieb: Given 2-tuples of type (T1, T2), you should be able to invoke the == operator if you could on both types T1 and T2, right?  i.e.

Re: [swift-users] is this a defect in equatable for swift tuples?

The == operator is defined for tuples with (up to 6) elements that conform to the Equatable protocol (and < for tuples with Comparable elements): class SomeClass: Equatable { static public func ==(_ lhs:SomeClass, _ rhs:SomeClass) -> Bool { return lhs === rhs }

Re: [swift-users] is this a defect in equatable for swift tuples?

Making SomeClass conform to Equatable should fix it: class SomeClass : Equatable { static public func ==(_ lhs:SomeClass, _ rhs:SomeClass) -> Bool { return lhs === rhs } } /Jens On Sun, Jul 9, 2017 at 5:11 PM, David Baraff via swift-users < swift-users@swift.org> wrote: >

[swift-users] is this a defect in equatable for swift tuples?

Given 2-tuples of type (T1, T2), you should be able to invoke the == operator if you could on both types T1 and T2, right? i.e. (“abc”, 3) == (“abc”, 4)// legal but: class SomeClass { static public func ==(_ lhs:SomeClass, _ rhs:SomeClass) -> Bool { return lhs === rhs

[swift-users] Exceptional values in the Comparable protocol

The Comparable protocol requires that < and == impose a strict total order: exactly one of a==b, ab must hold for all values a and b of a conforming type. But it is also noted that a conforming type may contain a subset of „exceptional values“ which do not take part in the strict total

Re: [swift-users] Filling two type parameters with the same type

Sorry Dave, I didn't notice that you said in `extension`. I just put the "where Source == Displacement" to the original poster's code and the error showed. My bad. Zhao Xin On Sun, Jul 9, 2017 at 1:56 PM, David Sweeris wrote: > Hmm... I just tried it in a playground, and