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

> On Nov 27, 2017, at 3:38 PM, Matthew Johnson via swift-evolution > wrote: > > You are effectively proposing that in this very narrow case we perform > overload resolution on a symbol in a generic type context *after* the generic > type has been replaced with a concrete type. Keep in mind

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

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 = “” } id() as Int // returns 0 id() as String // returns “” id() as SomeRandom

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

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: >>> they use packed buffers of floats, which for type safety are bett

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

> 28 Nov. 2017 00:57 Mathew Huusko V 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 actually true. Yes > "+" (/other

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

> On Nov 27, 2017, at 5:58 PM, Guillaume Lessard via swift-evolution > wrote: > > > >> On Nov 27, 2017, at 18:34, Douglas Gregor via swift-evolution >> wrote: >> >> Hello Swift community, >> >> The review of SE-0191 "Eliminate IndexDistance from Collection" begins now >> and runs throug

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

My suggestion would be: don’t have your Collection-like type conform to Collection. Give it collection-like methods if you want them, like an indexing and slicing subscript that takes an Int64. It can still conform to Sequence. In practice, these “huge” collections will be mostly used concretely

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

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(_:)”. But this is all just spelling now; I think the overall design is compelling in its elega

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

The proposal mentions one reasonable situation where a larger-than-Int type would be useful, namely a Collection wrapping a memory-mapped file, being used on 32-bit systems. Is there a recommended migration strategy for this scenario? Nevin On Mon, Nov 27, 2017 at 8:34 PM, Douglas Gregor via sw

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

> On Nov 25, 2017, at 3:16 PM, Chris Lattner via swift-evolution > 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 empty marker protocol like this: If you're reaching this point. why have a marker protocol at all? Why no

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

> On Nov 27, 2017, at 18: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. [snip] > • What is your evaluation of the proposal? I approve heartily. I

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

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-evolution/blob/master/proposals/0191-eliminate-indexdistance.md Reviews are an important part of the

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

On Mon, Nov 27, 2017 at 3:38 PM Matthew Johnson wrote: > On Nov 27, 2017, at 4:55 PM, Tony Allevato > wrote: > > > > On Mon, Nov 27, 2017 at 2:39 PM Matthew Johnson > wrote: > >> On Nov 27, 2017, at 4:25 PM, Tony Allevato >> wrote: >> >> >> >> On Mon, Nov 27, 2017 at 2:19 PM Matthew Johnson >

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

> On Nov 27, 2017, at 4:55 PM, Tony Allevato wrote: > > > > On Mon, Nov 27, 2017 at 2:39 PM Matthew Johnson > wrote: >> On Nov 27, 2017, at 4:25 PM, Tony Allevato > > wrote: >> >> >> >> On Mon, Nov 27, 2017 at 2:19 PM Matthew J

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

Hello, > Maybe we call the default RNG instance `random`, and then give the > `random(in:)` methods another name, like `choose(in:)`? > > let diceRoll = random.choose(in: 1...6) > let card = random.choose(in: deck) > let isHeads = random.choose(in: [true, false]) > let pr

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

On Mon, Nov 27, 2017 at 2:39 PM Matthew Johnson wrote: > On Nov 27, 2017, at 4:25 PM, Tony Allevato > wrote: > > > > On Mon, Nov 27, 2017 at 2:19 PM Matthew Johnson > wrote: > >> On Nov 27, 2017, at 3:56 PM, Howard Lovatt via swift-evolution < >> swift-evolution@swift.org> wrote: >> >> Really l

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

> On Nov 27, 2017, at 4:25 PM, Tony Allevato wrote: > > > > On Mon, Nov 27, 2017 at 2:19 PM Matthew Johnson > wrote: >> On Nov 27, 2017, at 3:56 PM, Howard Lovatt via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> Really like Tony’s suggest

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

On Mon, Nov 27, 2017 at 2:19 PM Matthew Johnson wrote: > On Nov 27, 2017, at 3:56 PM, Howard Lovatt via swift-evolution < > swift-evolution@swift.org> wrote: > > Really like Tony’s suggestion, much cleaner than yet another annotation > rammed into the signature. Also the idea of a static factory

[swift-evolution] [Accepted]

Hello Swift Community, The review of of “SE-0188: Make stdlib index types Hashable” ran from November 8th to 14th, 2017. This proposal has been accepted. During the review, the only point of discussion was whether to go one step further and make conformance to Hashable a requirement for all Col

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0189: Restrict Cross-module Struct Initializers

+1 from me. I have, all along, wished that we could use the designated/convenience initializer patterns with structs. This moves us a little bit closer, at least. On Mon, Nov 27, 2017 at 11:05 AM, Slava Pestov via swift-evolution < swift-evolution@swift.org> wrote: > > > On Nov 27, 2017, at 11

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

On Mon, Nov 27, 2017 at 2:19 PM Matthew Johnson wrote: > On Nov 27, 2017, at 3:56 PM, Howard Lovatt via swift-evolution < > swift-evolution@swift.org> wrote: > > Really like Tony’s suggestion, much cleaner than yet another annotation > rammed into the signature. Also the idea of a static factory

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

> On Nov 27, 2017, at 3:56 PM, Howard Lovatt via swift-evolution > wrote: > > Really like Tony’s suggestion, much cleaner than yet another annotation > rammed into the signature. Also the idea of a static factory that could > accept previously initialized arguments would be very powerful. I

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

You could even restrict to the same file, like extension access to private. -- Howard. > On 26 Nov 2017, at 9:44 am, Tony Allevato via swift-evolution > wrote: > >> On Sat, Nov 25, 2017 at 2:35 PM Xiaodi Wu wrote: >>> On Sat, Nov 25, 2017 at 4:25 PM, Tony Allevato >>> wrote: >> On Sa

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

> On Nov 27, 2017, at 3:27 PM, Tony Allevato wrote: > > On Mon, Nov 27, 2017 at 12:49 PM Matthew Johnson > wrote: >> On Nov 27, 2017, at 1:24 PM, Tony Allevato > > wrote: >> >> >> >> On Mon, Nov 27, 2017 at 11:12 AM Matthew Johns

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

Really like Tony’s suggestion, much cleaner than yet another annotation rammed into the signature. Also the idea of a static factory that could accept previously initialized arguments would be very powerful. -- Howard. > On 26 Nov 2017, at 9:25 am, Tony Allevato via swift-evolution > wrote:

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

> On Nov 22, 2017, at 8:55 PM, Alejandro Alonso via swift-evolution > wrote: > > I pushed some updates to the proposal with a reflected API, but I do not > agree that we should rid the API of T.random just because some users will > misuse it. I think the correct solution here is to include T.

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

On Mon, Nov 27, 2017 at 12:49 PM Matthew Johnson wrote: > On Nov 27, 2017, at 1:24 PM, Tony Allevato > wrote: > > > > On Mon, Nov 27, 2017 at 11:12 AM Matthew Johnson via swift-evolution < > swift-evolution@swift.org> wrote: > >> On Nov 27, 2017, at 12:50 PM, Douglas Gregor wrote: >> >> >> >> O

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

Thanks David, -Chris > On Nov 27, 2017, at 11:43 AM, David Owens wrote: > > I like the proposal. I think it’s simple and straight forward and provides > some really nice ergonomics for working with dynamic data. > > I appreciate the option to change the names too. > > If I understand it corr

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

> On Nov 27, 2017, at 12:54 PM, Dave DeLong wrote: > > Hi Chris, > > Some questions: > > 1️⃣ How does the subscript approach work for dynamically passing in multiple > parameters? For example, what would “dog.addTrick(“Roll Over”, favorite: > true)” be when expressed as a subscript method? T

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

Hi Chris, Some questions: 1️⃣ How does the subscript approach work for dynamically passing in multiple parameters? For example, what would “dog.addTrick(“Roll Over”, favorite: true)” be when expressed as a subscript method? The subscript syntax only really seems to suit property-style invocati

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

> On Nov 27, 2017, at 1:24 PM, Tony Allevato wrote: > > > > On Mon, Nov 27, 2017 at 11:12 AM Matthew Johnson via swift-evolution > mailto:swift-evolution@swift.org>> wrote: >> On Nov 27, 2017, at 12:50 PM, Douglas Gregor > > wrote: >> >> >> >>> On Nov 24, 2017, at

Re: [swift-evolution] [Review] SE-0190: Target environment platform condition

> On Nov 20, 2017, at 4:17 PM, Jonathan Hull via swift-evolution > wrote: > > I think the functionality is good, but I would like to see some thought on > what future values could be to see if this is the best name/structure. As mentioned in a bit more detail in the other email I just posted,

Re: [swift-evolution] [Review] SE-0190: Target environment platform condition

Sorry I was away last week, didn't see these review questions until now. > On Nov 20, 2017, at 2:58 PM, Rod Brown via swift-evolution > wrote: >> What is your evaluation of the proposal? >> > I think it’s good in theory, but I am concerned that there is currently only > one example case of “si

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

I like the proposal. I think it’s simple and straight forward and provides some really nice ergonomics for working with dynamic data. I appreciate the option to change the names too. If I understand it correctly, you could also call “add_trick” via: dog.addTrick("Roll over"); And simply update

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

On Mon, Nov 27, 2017 at 11:12 AM Matthew Johnson via swift-evolution < swift-evolution@swift.org> wrote: > On Nov 27, 2017, at 12:50 PM, Douglas Gregor wrote: > > > > On Nov 24, 2017, at 3:11 PM, Matthew Johnson via swift-evolution < > swift-evolution@swift.org> wrote: > > As mentioned in my prio

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

I'm sure the implementation is fine, and I'm not criticising the proposal's intent/concept, least of all simply because it might be misused (because everything can and is). Instead, I firmly believe — not to say I necessarily *deserve* a contrary explanation/argument if no one thinks this is a big

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

> On Nov 27, 2017, at 12:50 PM, Douglas Gregor wrote: > > > >> On Nov 24, 2017, at 3:11 PM, Matthew Johnson via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> As mentioned in my prior message, I currently have a PR open to update the >> generics manifesto (https://github

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0189: Restrict Cross-module Struct Initializers

> On Nov 27, 2017, at 11:04 AM, Ben Langmuir wrote: > > > >> On Nov 17, 2017, at 5:59 PM, Slava Pestov > > wrote: >> >> >> >>> On Nov 17, 2017, at 8:57 PM, Jordan Rose via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> >>> >>> On Nov 17

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0189: Restrict Cross-module Struct Initializers

> On Nov 17, 2017, at 5:59 PM, Slava Pestov wrote: > > > >> On Nov 17, 2017, at 8:57 PM, Jordan Rose via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> >> >>> On Nov 17, 2017, at 15:20, Ben Langmuir >> > wrote: >>> >>> Hi Jordan, >>> >>> F

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

On Nov 27, 2017, at 8:57 AM, Mathew Huusko V 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 actually true. Yes > "+" (/o

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

> On Nov 24, 2017, at 3:11 PM, Matthew Johnson via swift-evolution > wrote: > > As mentioned in my prior message, I currently have a PR open to update the > generics manifesto (https://github.com/apple/swift/pull/13012 > ). I removed one topic from

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

I like the proposal. Having a “magic” protocol isn’t ideal in some ways, but it seems like the best option for the moment, considering the other restrictions. The name “DynamicMemberLookupProtocol” is a bit unwieldy, though. What about something like “SupportsDynamicMemberLookup“ or "SupportsDyn

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

On Nov 27, 2017, at 6:37 AM, Mathew Huusko V wrote: > I tuned out the initial discussions of this proposal because there seemed to > be a lot of noise centered around implementation/maintainability. There was some noise, but as I believe the patch shows, it was misplaced. > I'm curious if the a

Re: [swift-evolution] [draft] Add last(where:) and lastIndex(where:) Methods

I like it, but only if the API is symmetric. However this would require the break existing API to make `firstIndex(where/of:)`.  One question: Can we maybe add retroactively an extra parameter with a default value? Something like: `func index(where predicate: (Element) throws -> Bool, traverse

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

> On Nov 27, 2017, at 2:56 AM, Tino Heth <2...@gmx.de> wrote: > > >> The implementation is straight-forward and (IMO) non-invasive in the >> compiler. > At least it’s smaller than I would have expected — but I don’t have the > overview to judge the consequences to the compiler. > > However, t

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

You say that all the `.random`s have different semantics, but to me (at least), they are all very similar. All the methods can be summarized as selecting a single random element from a collection `[0, 2, 3].random` selects a single element from the given collection `Int.random(in: 0…8)` selects

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

So why is it more important for the random method on a collection to have a special method that guarantees a discrete uniform distribution than it is for an Int? If you’re going to split on guaranteed-discrete-uniform vs maybe-discrete-uniform, why not split on discrete-uniform vs not-discrete

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

> 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 >> mailto:swift-evolution@swift.org>> wrote: >> >> when SE-185 >>

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

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 actually true. Yes "+" (/other math operators) and array access are unsafe, but most other

[swift-evolution] [draft] Add last(where:) and lastIndex(where:) Methods

Hello, Swift Evolution! This is a revision of a previous proposal for adding methods to sequences/collections for searching from the end. Feedback welcome! Nate — Add last(where:) and lastIndex(where:) Methods Proposal: SE- Author: Nate Cook Statu

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

> > Ah. You seem to be unfamiliar with protocol existentials. Protocols > (currently, only those without Self or associated type requirements, for > various implementation reasons) are themselves types. For example, you can > write: > A little offtopic, but I've been wanting to ask if it would be

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

> 27 Nov. 2017 22:38 Mathew Huusko V via swift-evolution > wrote: > > I tuned out the initial discussions of this proposal because there seemed to > be a lot of noise centered around implementation/maintainability. I'm curious > if the actual premise of the syntactic/sugar conversion has been

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

I tuned out the initial discussions of this proposal because there seemed to be a lot of noise centered around implementation/maintainability. I'm curious if the actual premise of the syntactic/sugar conversion has been discussed/debated yet? i.e. making dynamic/stringly calls look like normal call

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

> The implementation is straight-forward and (IMO) non-invasive in the compiler. At least it’s smaller than I would have expected — but I don’t have the overview to judge the consequences to the compiler. However, the impact those two proposals have on Swift is imho huge, and as the whole story

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

> Why do you need to have this ability to unsafe bitcast? Is interconversion > between point types such a common operation that it's a performance > bottleneck? A real-world example: Real-time image processing. When you have a stream of 4k pictures at 30 fps, you really don’t wont to copy buffer

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

> ps i remember that pitch because i’m pretty sure i was the one that pitched > that. No, I was writing about that one: https://www.mail-archive.com/swift-evolution@swift.org/msg30565.html > consensus seemed it was too high level for inclusion (even though having it > at the stdlib level would