Re: [swift-evolution] Feasibility of "T1 & ¬T2"

> On Nov 29, 2017, at 7:27 PM, Dave DeLong via swift-evolution > wrote: > > Hi SE, > > I’m pondering some esoteric type stuff as I’m sketching out an improved > date/time library (https://github.com/davedelong/Chronology > ), and I’m wondering two t

[swift-evolution] Feasibility of "T1 & ¬T2"

Hi SE, I’m pondering some esoteric type stuff as I’m sketching out an improved date/time library (https://github.com/davedelong/Chronology ), and I’m wondering two things: 1️⃣ Is there a way to express a type that does *not* conform to a protocol? For

Re: [swift-evolution] [Proposal] Random Unification

On Nov 28, 2017, at 11:10 PM, Thorsten Seitz via swift-evolution wrote: > > Shouldn't it be > > random.choose(from: 1...6) > > etc.? > > -Thorsten Doesn't `choose` usually take two arguments, the `count` to choose (presumably defaulting to 1) and the collection to choose `from`? -- E

Re: [swift-evolution] Remove AnyObject Constraint for Objective-C Lightweight Generics

> On Nov 9, 2017, at 9:01 AM, Philippe Hausler wrote: > > I have personally filed a few bugs on this; and I definitely consider it a > bug that we cannot store Any in generics for objc. There are however some > problem areas that might be worth considering while fixing this bug. > > 1) We ne

Re: [swift-evolution] Remove AnyObject Constraint for Objective-C Lightweight Generics

> On Nov 8, 2017, at 11:51 AM, Joe Groff wrote: > > In principle it makes sense, but there are implementation challenges we > didn't have time to consider. It would be nice to make this happen when we > have the time to make it work. Just out of curiosity, what were some of those implementati

Re: [swift-evolution] [Pitch] Improving KeyPath

I concur with Logan’s idea here on the general points, but let me add a bit more. Here are some KeyPathy things I’d like to see in a future Swift: /// A set of PartialKeyPath guaranteed as: /// (a) the entire set of keypaths for a type; and /// (b) accessible given the current scope Type.allKey

Re: [swift-evolution] [Pitch #2] Introduce User-defined "Dynamic Member Lookup" Types

> On Nov 29, 2017, at 07:25, Chris Lattner via swift-evolution > wrote: > > >> On Nov 29, 2017, at 12:46 AM, Brent Royal-Gordon >> wrote: >> >>> On Nov 28, 2017, at 8:35 PM, Chris Lattner wrote: >>> >>> We’ve had a lot of discussions over the years about how to balance >>> simplicity vs

Re: [swift-evolution] [Review] SE-0191: Eliminate IndexDistance from Collection

Distances, yes... *Count*, not necessarily. Em qua, 29 de nov de 2017 às 15:17, Xiaodi Wu escreveu: > Distance must be signed, so it cannot be UInt. > On Wed, Nov 29, 2017 at 11:14 Wallacy wrote: > >> I think is that's why some folks ask for count be UInt (or UInt64 when >> appropriate) some t

Re: [swift-evolution] [Review] SE-0191: Eliminate IndexDistance from Collection

Distance must be signed, so it cannot be UInt. On Wed, Nov 29, 2017 at 11:14 Wallacy wrote: > I think is that's why some folks ask for count be UInt (or UInt64 when > appropriate) some time ago. > > I dont know how solve this, but appear to be less painful than current > IndexDistance. > > Em qua

Re: [swift-evolution] [Review] SE-0191: Eliminate IndexDistance from Collection

I think is that's why some folks ask for count be UInt (or UInt64 when appropriate) some time ago. I dont know how solve this, but appear to be less painful than current IndexDistance. Em qua, 29 de nov de 2017 às 14:46, Ben Cohen via swift-evolution < swift-evolution@swift.org> escreveu: > You

Re: [swift-evolution] [Review] SE-0191: Eliminate IndexDistance from Collection

You can argue the current status is a bug, but… Welcome to Apple Swift version 4.0.1 (swiftlang-900.0.67 clang-900.0.38). Type :help for assistance. 1> CountableRange.IndexDistance.self $R0: Int.Type = Int 2> (Int64.min.. On Nov 29, 2017, at 4:04 AM, Xiaodi Wu wrote: > > So that we are all

Re: [swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

> On Nov 28, 2017, at 10:54 PM, Chris Lattner wrote: > >> On Nov 28, 2017, at 10:12 AM, Paul Cantrell > > wrote: >> Chris wrote: >>> Paul wrote: An “always use parens” bridge to Ruby has bad ergonomics Zero-arg Ruby methods are a mixture of property-like thi

Re: [swift-evolution] [Pitch #2] Introduce User-defined "Dynamic Member Lookup" Types

> On Nov 29, 2017, at 12:46 AM, Brent Royal-Gordon > wrote: > >> On Nov 28, 2017, at 8:35 PM, Chris Lattner wrote: >> >> We’ve had a lot of discussions over the years about how to balance >> simplicity vs power, implicitness vs explicitness, intentionality vs >> accidental behavior, etc. F

Re: [swift-evolution] [Pitch #2] Introduce User-defined "Dynamic Member Lookup" Types

> On Nov 29, 2017, at 2:21 AM, Jonathan Hull wrote: > > I noticed all of the examples return the same type as they are defined on > (JSON has a subscript that returns JSON). Is there an example of where this > is not the case? Yes, they exist, there is one in the Python interop layer that I’

Re: [swift-evolution] [Review] SE-0191: Eliminate IndexDistance from Collection

So that we are all clear on the implications of this, if IndexDistance becomes Int, ranges of integers will stop conforming to Collection, because Int.min.. wrote: > My suggestion would be: don’t have your Collection-like type conform to > Collection. Give it collection-like methods if you want th

Re: [swift-evolution] [Pitch #2] Introduce User-defined "Dynamic Member Lookup" Types

I noticed all of the examples return the same type as they are defined on (JSON has a subscript that returns JSON). Is there an example of where this is not the case? > On Nov 25, 2017, at 3:16 PM, Chris Lattner via swift-evolution > wrote: > > On Nov 20, 2017, at 10:36 PM, Chris Lattner <

Re: [swift-evolution] [Pitch #2] Introduce User-defined "Dynamic Member Lookup" Types

> On Nov 28, 2017, at 8:35 PM, Chris Lattner wrote: > > We’ve had a lot of discussions over the years about how to balance simplicity > vs power, implicitness vs explicitness, intentionality vs accidental > behavior, etc. For example, in very early discussions about Swift generics, > some fol