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

> On 28. Nov 2017, at 02:34, Douglas Gregor via swift-evolution > wrote: > > Hello Swift community, > > The review of SE-0191 "Eliminate IndexDistance from Collection" begins now > and runs through December 3, 2017. The proposal is available here: > > https://github.com/apple/swift-evolutio

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

Shouldn't it be random.choose(from: 1...6) etc.? -Thorsten > Am 28.11.2017 um 00:20 schrieb Martin Waitz via swift-evolution > : > > Hello, > >> Maybe we call the default RNG instance `random`, and then give the >> `random(in:)` methods another name, like `choose(in:)`? >> >>let d

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

> On Nov 28, 2017, at 8:33 PM, Tony Allevato wrote: > > On Tue, Nov 28, 2017 at 11:23 AM Kelvin Ma via swift-evolution > wrote: > On Tue, Nov 28, 2017 at 12:59 PM, Joe Groff via swift-evolution > wrote: > > > > On Nov 28, 2017, at 10:52 AM, Vladimir.S wrote: > > > > On 27.11.2017 20:28,

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

> On Nov 28, 2017, at 8:57 PM, Slava Pestov wrote: > > Hi Chris, > >> On Nov 28, 2017, at 8:54 PM, Chris Lattner via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> “post.author" always invokes the DynamicMemberLookupProtocol proposal. >> “post.author()” would invoke the “D

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

Hi Chris, > On Nov 28, 2017, at 8:54 PM, Chris Lattner via swift-evolution > wrote: > > “post.author" always invokes the DynamicMemberLookupProtocol proposal. > “post.author()” would invoke the “DynamicCallableWithKeywordsToo” hook in the > dynamic callable proposal: > https://gist.github.com/

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

> 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 things that would >>> certainly not use parens in Swift, and function-like things that certainly

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

> On Nov 27, 2017, at 9:03 PM, Magnus Ahltorp wrote: > Also, if the bridge author wants to return optionals all the time, that is > possible, right? Yes, absolutely. An example of that is already in the proposal. -Chris ___ swift-evolution mailing

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

> On Nov 28, 2017, at 5:58 PM, Greg Parker via swift-evolution > wrote: > > >> On Nov 27, 2017, at 8:57 AM, Mathew Huusko V via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> You're saying that there is universally no inherent difference, and that all >> calls "determine

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

+1. Feels more Swifty to keep things simple when additional complexity isn’t warrented. > Hello Swift community, > > > The review of SE-0191 "Eliminate IndexDistance from Collection" begins now > and runs through December 3, 2017. The proposal is available here: > > > https://github.com/apple

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

> On Nov 28, 2017, at 1:55 PM, Ben Rimmington wrote: > > I suggest using different subscripts for function/method calls and properties: > > * `value(...)` ==> `value[dynamicFunction: ""](...)` > * `value.name(...)` ==> `value[dynamicFunction: "name"](...)` > * `value.name` ==> `value[

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

> On Nov 27, 2017, at 7:31 PM, Xiaodi Wu wrote: > > Better yet, since we previously started to require “@objc dynamic” instead of > “dynamic” with the notion that perhaps there would be some future non-ObjC > dynamism, we *could* have it spelt “dynamic member(_:)”. I’m super open the changing

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

> On Nov 27, 2017, at 6:21 PM, Brent Royal-Gordon > wrote: > >> On Nov 25, 2017, at 3:16 PM, Chris Lattner via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> Just to talk to myself a bit here, but I’ve come to realize that the right >> design really is to have a simple em

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

On Tue, Nov 28, 2017 at 11:23 AM Kelvin Ma via swift-evolution < swift-evolution@swift.org> wrote: > On Tue, Nov 28, 2017 at 12:59 PM, Joe Groff via swift-evolution < > swift-evolution@swift.org> wrote: > >> >> >> > On Nov 28, 2017, at 10:52 AM, Vladimir.S wrote: >> > >> > On 27.11.2017 20:28, Jo

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

> On Nov 27, 2017, at 8:57 AM, Mathew Huusko V via swift-evolution > wrote: > > You're saying that there is universally no inherent difference, and that all > calls "determine if you have called it" correctly, but then picked one of > only a handful of cases in current practice where that is

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

+1. It seems like a practical first step. > On Nov 28, 2017, at 10:59 AM, Joe Groff via swift-evolution > wrote: > > > >> On Nov 28, 2017, at 10:52 AM, Vladimir.S wrote: >> >> On 27.11.2017 20:28, Joe Groff via swift-evolution wrote: On Nov 20, 2017, at 5:43 PM, Chris Lattner via swif

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

> On 28 Nov 2017, at 22:06, Jean-Daniel wrote: > > While I perfectly understand why subscript is the best way to represent > dynamic property, I don’t get how it help to abuse it to implement dynamic > methods. Methods are not l-value, so why do you want to use a subscript for > them ? First,

[swift-evolution] Update: Moving to Discourse

Hi All- I just wanted to update you all on our migration to Discourse. We are well on our way, with a prototype server and initial import of mailing list data completed! As part of the move to Discourse, we have the opportunity to do some re-organization to help foster communication and coll

Re: [swift-evolution] [Pre-pitch] Conditional default arguments

> On Nov 28, 2017, at 4:11 PM, Slava Pestov wrote: > > > >> On Nov 28, 2017, at 1:35 PM, Matthew Johnson > > wrote: >> * the compiler doesn’t have to reason about an overload set which might improve build times, etc >>> >>> They’re effectively equiva

Re: [swift-evolution] [Pre-pitch] Conditional default arguments

> On Nov 28, 2017, at 1:35 PM, Matthew Johnson wrote: > >>> * the compiler doesn’t have to reason about an overload set which might >>> improve build times, etc >> >> They’re effectively equivalent, because we still have to decide which subset >> of the default arguments apply at a given cal

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

> Le 28 nov. 2017 à 22:56, Ben Rimmington via swift-evolution > a écrit : > > I suggest using different subscripts for function/method calls and properties: > While I perfectly understand why subscript is the best way to represent dynamic property, I don’t get how it help to abuse it to imp

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

I suggest using different subscripts for function/method calls and properties: * `value(...)` ==> `value[dynamicFunction: ""](...)` * `value.name(...)` ==> `value[dynamicFunction: "name"](...)` * `value.name` ==> `value[dynamicProperty: "name"]` Dynamic callable types have an unnamed me

Re: [swift-evolution] [Pre-pitch] Conditional default arguments

> On Nov 28, 2017, at 3:28 PM, Slava Pestov wrote: > > > >> On Nov 28, 2017, at 1:25 PM, Matthew Johnson > > wrote: >> >> >>> On Nov 28, 2017, at 3:18 PM, Slava Pestov >> > wrote: >>> >>> >>> On Nov 28, 2017, at 8:44 AM, Matthe

Re: [swift-evolution] [Pre-pitch] Conditional default arguments

> On Nov 28, 2017, at 1:25 PM, Matthew Johnson wrote: > > >> On Nov 28, 2017, at 3:18 PM, Slava Pestov > > wrote: >> >> >> >>> On Nov 28, 2017, at 8:44 AM, Matthew Johnson >> > wrote: >>> >>> func makeResource( >>> with configura

Re: [swift-evolution] [Pre-pitch] Conditional default arguments

> On Nov 28, 2017, at 3:18 PM, Slava Pestov wrote: > > > >> On Nov 28, 2017, at 8:44 AM, Matthew Johnson > > wrote: >> >> func makeResource( >> with configuration: Configuration = () where Configuration == Void, >> actionHandler: @escaping (Action) -> V

Re: [swift-evolution] [Pre-pitch] Conditional default arguments

> On Nov 28, 2017, at 8:44 AM, Matthew Johnson wrote: > > func makeResource( > with configuration: Configuration = () where Configuration == Void, > actionHandler: @escaping (Action) -> Void = { _ in } where Action == Never > ) Similar question to the one I posed earlier — what happen

Re: [swift-evolution] [Pitch] Make Optional, Array, and Dictionary conditionally Equatable

On Tue, Nov 28, 2017 at 1:05 PM, Douglas Gregor via swift-evolution < swift-evolution@swift.org> wrote: > > To close the loop here, the core team has agreed to this as an amendment > to SE-0143, and the changed has been merged here: > > https://github.com/apple/swift-evolution/pull/769 > > and we’

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

On Tue, Nov 28, 2017 at 12:59 PM, Joe Groff via swift-evolution < swift-evolution@swift.org> wrote: > > > > On Nov 28, 2017, at 10:52 AM, Vladimir.S wrote: > > > > On 27.11.2017 20:28, Joe Groff via swift-evolution wrote: > >>> On Nov 20, 2017, at 5:43 PM, Chris Lattner via swift-evolution < > sw

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

On Tue, Nov 28, 2017 at 3:18 AM, Xiaodi Wu wrote: > > On Tue, Nov 28, 2017 at 00:32 Kelvin Ma wrote: > >> On Mon, Nov 27, 2017 at 9:43 PM, Xiaodi Wu wrote: >> >>> On Mon, Nov 27, 2017 at 5:56 PM, Kelvin Ma wrote: >>> On Mon, Nov 27, 2017 at 4:21 PM, Xiaodi Wu wrote: >

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

> On Nov 28, 2017, at 10:52 AM, Vladimir.S wrote: > > On 27.11.2017 20:28, Joe Groff via swift-evolution wrote: >>> On Nov 20, 2017, at 5:43 PM, Chris Lattner via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> >>> On Nov 20, 2017, at 5:39 PM, Kelvin Ma via swift-evolu

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

On 27.11.2017 20:28, Joe Groff via swift-evolution wrote: On Nov 20, 2017, at 5:43 PM, Chris Lattner via swift-evolution > wrote: On Nov 20, 2017, at 5:39 PM, Kelvin Ma via swift-evolution > wrote: when SE-185

[swift-evolution] [Accepted] SE-0190 - Target environment platform condition

Hello Swift Community, The review of of “SE-190: Target environment platform condition” ran from November 16 to 24, 2017. This proposal has been accepted. During the review, support for the enhancement was unanimous. There were some questions during the review about the capabilities of this fe

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

I’m not sure this solves the Ruby ergonomics problem. Picking up from an earlier thread: Chris wrote: > Paul wrote: >> An “always use parens” bridge to Ruby has bad ergonomics >> Zero-arg Ruby methods are a mixture of property-like things that would >> certainly not use parens in Swift, and func

Re: [swift-evolution] [Pitch] Make Optional, Array, and Dictionary conditionally Equatable

> On Nov 26, 2017, at 9:21 PM, John McCall wrote: > >> >> On Nov 22, 2017, at 1:08 PM, Douglas Gregor via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> >> >> Sent from my iPhone >> >> On Nov 22, 2017, at 9:48 AM, Chris Lattner > > wrote: >>

Re: [swift-evolution] [Pre-pitch] Conditional default arguments

> On Nov 28, 2017, at 11:40 AM, Tony Allevato wrote: > > > > On Tue, Nov 28, 2017 at 9:16 AM Matthew Johnson > wrote: >> On Nov 28, 2017, at 11:01 AM, Tony Allevato > > wrote: >> >> >> >> On Tue, Nov 28, 2017 at 8:45 AM Matthew

Re: [swift-evolution] [Pre-pitch] Conditional default arguments

On Tue, Nov 28, 2017 at 9:16 AM Matthew Johnson wrote: > On Nov 28, 2017, at 11:01 AM, Tony Allevato > wrote: > > > > On Tue, Nov 28, 2017 at 8:45 AM Matthew Johnson > wrote: > >> On Nov 28, 2017, at 10:06 AM, Tony Allevato >> wrote: >> >> >> >> On Mon, Nov 27, 2017 at 10:32 PM Slava Pestov w

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

On Mon, Nov 27, 2017 at 5:34 PM Douglas Gregor via swift-evolution < swift-evolution@swift.org> wrote: > Hello Swift community, > > The review of SE-0191 "Eliminate IndexDistance from Collection" begins now > and runs through December 3, 2017. The proposal is available here: > > > https://github.c

Re: [swift-evolution] [Pre-pitch] Conditional default arguments

> On Nov 28, 2017, at 11:01 AM, Tony Allevato wrote: > > > > On Tue, Nov 28, 2017 at 8:45 AM Matthew Johnson > wrote: >> On Nov 28, 2017, at 10:06 AM, Tony Allevato > > wrote: >> >> >> >> On Mon, Nov 27, 2017 at 10:32 PM Slava

Re: [swift-evolution] [Pre-pitch] Conditional default arguments

On Tue, Nov 28, 2017 at 8:45 AM Matthew Johnson wrote: > On Nov 28, 2017, at 10:06 AM, Tony Allevato > wrote: > > > > On Mon, Nov 27, 2017 at 10:32 PM Slava Pestov wrote: > >> Hi Tony, >> >> So if my understanding is correct, the basic proposal is the following: >> >> func id(t: T ?= T.defaultV

Re: [swift-evolution] [Pre-pitch] Conditional default arguments

> On Nov 28, 2017, at 10:06 AM, Tony Allevato wrote: > > > > On Mon, Nov 27, 2017 at 10:32 PM Slava Pestov > wrote: > Hi Tony, > > So if my understanding is correct, the basic proposal is the following: > > func id(t: T ?= T.defaultValue) { return t } > > extensio

Re: [swift-evolution] [Pre-pitch] Conditional default arguments

On Mon, Nov 27, 2017 at 10:32 PM Slava Pestov wrote: > Hi Tony, > > So if my understanding is correct, the basic proposal is the following: > > func id(t: T ?= T.defaultValue) { return t } > > extension Int { static var defaultValue = 0 } > > extension String { static var defaultValue = “” } > >

Re: [swift-evolution] [Pre-pitch] Conditional default arguments

> On Nov 28, 2017, at 12:34 AM, Slava Pestov wrote: > > > >> On Nov 27, 2017, at 3:38 PM, Matthew Johnson via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> You are effectively proposing that in this very narrow case we perform >> overload resolution on a symbol in a gen

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

I think this thread derailed quite a bit — it might have even been a good thing that some discussion accidentally went off-list ;-) Personally, I think it's nice if tuples and structs would converge more, so that either struct is seen as an extension of the tuple-concept, or tuple is considered

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

On Tue, Nov 28, 2017 at 00:32 Kelvin Ma wrote: > On Mon, Nov 27, 2017 at 9:43 PM, Xiaodi Wu wrote: > >> On Mon, Nov 27, 2017 at 5:56 PM, Kelvin Ma wrote: >> >>> >>> >>> On Mon, Nov 27, 2017 at 4:21 PM, Xiaodi Wu wrote: >>> On Mon, Nov 27, 2017 at 15:46 Taylor Swift wrote: >

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

Hi list, > On 28. Nov 2017, at 02:34, Douglas Gregor via swift-evolution > wrote: > > The review of SE-0191 "Eliminate IndexDistance from Collection" begins now > and runs through December 3, 2017. The proposal is available here: > > • What is your evaluation of the proposal? +1. >