[swift-evolution] [Review] SE-0194: Derived Collection of Enum Cases

Hello Swift community, The review of SE-0194 "Derived Collection of Enum Cases" begins now and runs through January 11, 2018. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0194-derived-collection-of-enum-cases.md Reviews are an important part of

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

> On Dec 1, 2017, at 9:37 AM, Chris Lattner wrote: > > On Dec 1, 2017, at 12:26 AM, Douglas Gregor > wrote: >>> On Nov 30, 2017, at 10:05 PM, Chris Lattner >> > wrote: >>> Hi

Re: [swift-evolution] [RFC] Associated type inference

> On Dec 2, 2017, at 9:23 PM, Dave Abrahams <dabrah...@apple.com> wrote: > > > On Nov 30, 2017, at 2:28 PM, Douglas Gregor via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> What’s a Good Solution Look Like? &g

Re: [swift-evolution] [RFC] Associated type inference

> Again, sorry for the noise if this is unrelated to the discussion. - Doug > /Jens > > > On Sun, Dec 3, 2017 at 6:23 AM, Dave Abrahams via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > > On Nov 30, 20

Re: [swift-evolution] [RFC] Associated type inference

> On Dec 1, 2017, at 11:42 AM, Nevin Brackett-Rozinsky > <nevin.brackettrozin...@gmail.com> wrote: > > On Thu, Nov 30, 2017 at 7:28 PM, Douglas Gregor via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > A Rough

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

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0191-eliminate-indexdistance.md Hello Swift Community, The review of SE-0191 "Eliminate IndexDistance from Collection” ran from November 27…December 3, 2017. The proposal is accepted. Feedback for this

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

ion. >> >>> On Nov 27, 2017, at 19:29, Nevin Brackett-Rozinsky via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>> >>> The proposal mentions one reasonable situation where a larger-than-Int type &g

Re: [swift-evolution] [RFC] Associated type inference

Sent from my iPhone > On Dec 2, 2017, at 1:37 PM, Matthew Johnson <matt...@anandabits.com> wrote: > > >> On Nov 30, 2017, at 6:28 PM, Douglas Gregor via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> Hello Swift community, >>

Re: [swift-evolution] [RFC] Associated type inference

> On Dec 1, 2017, at 10:07 AM, Greg Titus wrote: > > > >> On Dec 1, 2017, at 9:11 AM, Ben Langmuir via swift-evolution >> > wrote: >> Hey Doug, >> >> I'm very much in favour of reducing the scope of associated

Re: [swift-evolution] [RFC] Associated type inference

> On Dec 1, 2017, at 9:11 AM, Ben Langmuir <blangm...@apple.com> wrote: > >> >> On Nov 30, 2017, at 4:28 PM, Douglas Gregor via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> Hello Sw

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

> On Dec 1, 2017, at 1:30 AM, Chris Lattner wrote: > >> On Dec 1, 2017, at 12:26 AM, Douglas Gregor > > wrote: Philosophy > >>> More problematically for your argument: your preferred approach requires >>> the

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

> On Nov 30, 2017, at 10:05 PM, Chris Lattner wrote: > > Hi Doug, > > Thank you for the detailed email. I have been traveling today, so I haven’t > had a chance to respond until now. I haven’t read the down-thread emails, so > I apologize if any of this was already

[swift-evolution] [RFC] Associated type inference

Hello Swift community, Associated type inference, which is the process by which the Swift compiler attempts to infer typealiases to satisfy associated-type requirements based on other requirements, has caused both implementation problems and user confusion for a long time. Some of you might

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

As noted at the end of my message, I think one can write a Swift library to make working with the Python runtime much easier, and write a wrapper generator that produces Swift APIs from Python code that use said Swift library. - Doug > > On Nov 30, 2017, at 2:24 AM, Douglas Gregor

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

> On Nov 26, 2017, at 10:04 PM, Chris Lattner via swift-evolution > wrote: > > I’d like to formally propose the inclusion of user-defined dynamic member > lookup types. > > Here is my latest draft of the proposal: >

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 >

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

> On Nov 26, 2017, at 9:21 PM, John McCall <rjmcc...@apple.com> wrote: > >> >> On Nov 22, 2017, at 1:08 PM, Douglas Gregor via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> >> >

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

> On Nov 27, 2017, at 5:58 PM, Guillaume Lessard via swift-evolution > <swift-evolution@swift.org> wrote: > > > >> On Nov 27, 2017, at 18:34, Douglas Gregor via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> Hello Swift

[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

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 >

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

Sent from my iPhone > On Nov 24, 2017, at 4:06 PM, Chris Lattner <clatt...@nondot.org> wrote: > >> On Nov 24, 2017, at 3:47 PM, Douglas Gregor via swift-evolution >> <swift-evolution@swift.org> wrote: >> One could imagine adding a “curry” operation to fu

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

com > > <mailto:da...@hartbit.com>> wrote: > > > > On 22 Nov 2017, at 07:41, Douglas Gregor via swift-evolution > > <swift-evolution@swift.org <mailto:swift-evolution@swift.org> > > <mailto:swift-evolution@swift.org <mailto:swift-evolution@swif

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

Sent from my iPhone > On Nov 22, 2017, at 10:12 AM, Dave DeLong <sw...@davedelong.com> wrote: > > > >> On Nov 21, 2017, at 11:51 PM, Douglas Gregor via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> Hi all, >> >> We

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

e and lazy types is big enough to warrant a proposal, for example. - Doug > > -Chris > >> On Nov 21, 2017, at 10:51 PM, Douglas Gregor via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> Hi all, >> >> We’re having a bit of a

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

> On Nov 21, 2017, at 10:48 PM, David Hart <da...@hartbit.com> wrote: > > > > On 22 Nov 2017, at 07:41, Douglas Gregor via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > >> >> >>> On N

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

Hi all, We’re having a bit of a debate over the question of whether SE-0143 “Conditional Conformances” actually proposes any standard library changes at

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

> On Nov 21, 2017, at 10:37 PM, Chris Lattner wrote: > > On Nov 21, 2017, at 9:25 PM, Douglas Gregor > wrote: >>> Or alternatively, one could decide to make the generics system *only and >>> forever* work on nominal types,

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

> On Nov 21, 2017, at 9:21 PM, Chris Lattner <clatt...@nondot.org> wrote: > > > >> On Nov 21, 2017, at 7:19 PM, Douglas Gregor via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> >>

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

1, 2017 at 3:10 PM Douglas Gregor via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> >>>> On Nov 21, 2017, at 3:05 PM, Slava Pestov <spes...@apple.com> wrote: >>>> >>>> >>>> >>>> On No

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

> On Nov 21, 2017, at 3:05 PM, Slava Pestov wrote: > > > >> On Nov 21, 2017, at 6:02 PM, David Hart > > wrote: >> >> Can somebody explain to me what are >> nominal and structural types and why Optional should really be a

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

> On Nov 20, 2017, at 6:07 PM, Tony Allevato via swift-evolution > wrote: > > This is something I've wanted to look at for a while. A few weeks ago I > pushed out https://github.com/apple/swift/pull/12598 > to extend the

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

> On Nov 20, 2017, at 6:17 PM, Chris Lattner via swift-evolution > wrote: > > Yes, I agree, we need variadic generics before we can have tuples conform :-( Well, we don’t *have* to have variadic generics to allow structural types to conform… it just composes

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

> On Nov 20, 2017, at 10:31 PM, Chris Lattner wrote: > > > >> On Nov 20, 2017, at 10:24 PM, David Hart > > wrote: >> >> >> >> On 21 Nov 2017, at 03:17, Chris Lattner via swift-evolution >>

Re: [swift-evolution] [Discussion] Swift for Data Science / ML / Big Data analytics

> On Oct 30, 2017, at 9:43 PM, Chris Lattner wrote: > > JohnMC: question for you below. > > On Oct 30, 2017, at 1:25 PM, Douglas Gregor > wrote: >>> >>> Thinking about the Perl case makes it clear to me that this should not

Re: [swift-evolution] [Discussion] Swift for Data Science / ML / Big Data analytics

Swift somehow (and keep it usable). - Doug > > - David > >> On Oct 30, 2017, at 13:25, Douglas Gregor via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> >> >>> On Oct 29,

Re: [swift-evolution] [Discussion] Swift for Data Science / ML / Big Data analytics

> On Oct 29, 2017, at 1:34 PM, Chris Lattner via swift-evolution > wrote: > >> >> On Oct 29, 2017, at 8:23 AM, Chris Lattner via swift-evolution >> wrote: >> >> >>> On Oct 29, 2017, at 4:04 AM, Lukas Stabe wrote: >>>

[swift-evolution] [Accepted with revisions] SE-0184: Unsafe[Mutable][Raw][Buffer]Pointer: add missing methods, adjust existing labels for clarity, and remove deallocation size

Hello Swift community, Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0184-unsafe-pointers-add-missing.md The review of SE-0184 "Unsafe[Mutable][Raw][Buffer]Pointer: add missing methods, adjust existing labels for clarity, and remove deallocation size”

Re: [swift-evolution] Problems with generics - should be fixed for Xcode 9?

Sent from my iPhone > On Sep 16, 2017, at 6:32 AM, Joanna Carter via swift-evolution > wrote: > > Greetings > > Old chestnut, sort of partially solved but still problems. > > Now we can nest types in generic types, what I want is : > > class Event > { > class

[swift-evolution] [Review] SE-0184: Unsafe[Mutable][Raw][Buffer]Pointer: add missing methods, adjust existing labels for clarity, and remove deallocation size

Hello Swift community, The review of SE-0184 "Unsafe[Mutable][Raw][Buffer]Pointer: add missing methods, adjust existing labels for clarity, and remove deallocation size" begins now and runs through September 7, 2017. The proposal is available here:

Re: [swift-evolution] [Pitch] Introducing role keywords to reduce hard-to-find bugs

> On Jun 16, 2017, at 11:21 AM, Tino Heth via swift-evolution > wrote: > > The described problem might be one of the most famous itches of the language, > but imho the bar for new keywords* should be higher than that — and there are > alternatives: > > First, I

Re: [swift-evolution] Preparing Swift compiler stage reentrancy in preparation for "constexpr"

> On Aug 19, 2017, at 12:27 PM, Daryle Walker via swift-evolution > wrote: > > [I’m not sure which list should cover this.] > > I once thought of having a “#protocols(SomeTypeOrProtocol)” that was a type > alias to a composition of all protocols the given

Re: [swift-evolution] Constrained Protocol Aliases

> On Aug 21, 2017, at 5:51 AM, David Hart wrote: > > >> On 21 Aug 2017, at 13:36, Adrian Zubarev > > wrote: >> >> It’s part of Generalized Existentials, but does not make it complete. I >> think it

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0185 - Synthesizing Equatable and Hashable conformance

Sent from my iPhone > On Aug 9, 2017, at 10:37 PM, Adrian Zubarev via swift-evolution > wrote: > > Well, if there is one, then I apologize for bothering anyone. I just assumed > it would be included in the proposal itself, and I couldn't find it myself. > ;)

Re: [swift-evolution] [planning] [discussion] Schedule for return of closure parameter labels (+ world domination ramble)

> On Aug 8, 2017, at 10:44 AM, Mathew Huusko V via swift-evolution > wrote: > > Sorry to revive this, but back on my ABI stability education: [We’re a bit far afield of the original subject, but okay] > > Swift 5 planning was announced today (woohoo!) with a

[swift-evolution] [Core team] Addressing the SE-0110 usability regression in Swift 4

Hello Swift community, Swift 3’s SE-0110 eliminated the equivalence between function types that accept a single type and function types that take multiple arguments. However, for various

Re: [swift-evolution] The state and the future of function types in Swift 4

> On Jun 14, 2017, at 3:29 PM, Vladimir.S via swift-evolution > wrote: > > I do understand that core team is very busy, but I hope they'll find a minute > to reply in couple of words to this message. Even "we are still thinking > about this" would be great. Of

Re: [swift-evolution] Introduction of OrderedSet

ly concepts like the Collection protocols. >> >> Sure, we’d need to design it to fit well with the standard library and >> provide the APIs people expect from NSOrderedSet. >> >> - Doug >> >>> - Tony >>> >>>>> On Jun 9, 20

Re: [swift-evolution] Introduction of OrderedSet

library and provide the APIs people expect from NSOrderedSet. - Doug > - Tony > >> On Jun 9, 2017, at 4:28 PM, Douglas Gregor via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >>> >>> On

Re: [swift-evolution] Introduction of OrderedSet

> On Jun 9, 2017, at 10:19 AM, Xiaodi Wu via swift-evolution > wrote: > > Let me try to redirect this conversation, if I may. > > As far as I can tell, SE-0069 states plainly that the plan of record is to > offer a value type called OrderedSet in Foundation, but

[swift-evolution] [Accepted] SE-0174: Change filter to return an associated type

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0174-filter-range-replaceable.md Hello Swift Community, The review of SE-0174 "Change filter to return an associated type” ran from April 28...May 3, 2017. The proposal is accepted. Thank you to everyone who

Re: [swift-evolution] Replace throws with Result

> On May 3, 2017, at 3:31 AM, Jaden Geller via swift-evolution > wrote: > > To be frank, there’s no way this is happening. The rationale for Swift’s > error handling is documented > , and this >

[swift-evolution] [Review] SE-0174: Change `filter` to return an associated type

Hello Swift community, The review of SE-0174 "Change `filter` to return an associated type" begins now and runs through May 3, 2017. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0174-filter-range-replaceable.md Reviews are an important part of

[swift-evolution] [Accepted] SE-0167: Swift Encoders

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0167-swift-encoders.md The review of SE-0167 "SE-0167: Swift Encoders” ran from April 6...12, 2017. The proposal is accepted.

[swift-evolution] [Accepted] SE-0166: Swift Archival & Serialization

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0166-swift-archival-serialization.md Hello Swift Community, The review of SE-0166 “Swift Archival &

Re: [swift-evolution] [Pitch] Enum with generic cases

> On Apr 24, 2017, at 12:57 PM, Joshua Alvarado > wrote: > > When would be a good time to resubmit this proposal for discussion? Sometime in the summer we’re going to start talking about the scope of Swift post-4.0. > Or can I still proceed with the review and it

Re: [swift-evolution] [Accepted] SE-0172: One-sided Ranges

> On Apr 25, 2017, at 9:20 AM, Tony Allevato wrote: > > > On Tue, Apr 25, 2017 at 8:55 AM Haravikk via swift-evolution > > wrote: > While it's good that this was accepted I still feel there could be some

[swift-evolution] [Accepted] SE-0172: One-sided Ranges

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0172-one-sided-ranges.md Hello Swift Community, The review of SE-0172 “One-sided Ranges” ran from April 17...23, 2017. The proposal is accepted for Swift 4. Thanks to everyone who participated in the discussion!

Re: [swift-evolution] [Pitch] Enum with generic cases

> On Apr 24, 2017, at 7:23 AM, T.J. Usiyan via swift-evolution > wrote: > > /me Pushes implementation detail related concerns out of head > > +1 > > > I want this feature but I seriously doubt that it is feasible at the moment. > There are so many 'more pressing'

Re: [swift-evolution] [Accepted] SE-0169: Improve Interaction Between `private` Declarations and Extensions

, Douglas Gregor <dgre...@apple.com >>>> <mailto:dgre...@apple.com>> wrote: >>>> >>>> >>>>> On Apr 20, 2017, at 11:33 AM, Jordan Rose <jordan_r...@apple.com >>>>> <mailto:jordan_r...@apple.com>> wrote: >>&

Re: [swift-evolution] [Review] SE-0172: One-sided Ranges

generics are a long way off and the syntax is totally up in the air. - Doug > -Matt > >> On Apr 17, 2017, at 21:40, Douglas Gregor via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> Hello Swift community

Re: [swift-evolution] [Accepted] SE-0169: Improve Interaction Between `private` Declarations and Extensions

Gregor <dgre...@apple.com >> <mailto:dgre...@apple.com>> wrote: >> >> >>> On Apr 20, 2017, at 11:33 AM, Jordan Rose <jordan_r...@apple.com >>> <mailto:jordan_r...@apple.com>> wrote: >>> >>> >>>> On A

Re: [swift-evolution] [Accepted] SE-0169: Improve Interaction Between `private` Declarations and Extensions

> On Apr 20, 2017, at 11:33 AM, Jordan Rose <jordan_r...@apple.com> wrote: > > >> On Apr 18, 2017, at 20:40, Douglas Gregor via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> This m

Re: [swift-evolution] [Accepted] SE-0169: Improve Interaction Between `private` Declarations and Extensions

extension P where Self : Q { } Might be a better spelling than extension P & Q { } Despite the latter being more obvious :) - Doug > > >> On Mon, Apr 17, 2017 at 19:25 Douglas Gregor via swift-evolution >> <swift-evolution@swift.org> wrote: >> Proposal

[swift-evolution] [Review] SE-0172: One-sided Ranges

Hello Swift community, The review of SE-0172 "One-sided Ranges" begins now and runs through April 23, 2017. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0172-one-sided-ranges.md Reviews are an important part of the Swift evolution process. All

[swift-evolution] [Accepted] SE-0169: Improve Interaction Between `private` Declarations and Extensions

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md Hello

[swift-evolution] [Accepted] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0161-key-paths.md The second review of SE-0161 "Smart KeyPaths: Better Key-Value Coding for Swift” ran April 5...9, 2017. The first

[swift-evolution] [Accepted] SE-0164: Remove final support in protocol extensions

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0164-remove-final-support-in-protocol-extensions.md The review of SE-0164 "Remove final support in protocol extensions” ran from April 5...8, 2017. Feedback was light but positive, and the proposal is accepted.

Re: [swift-evolution] [Pitch] Adding safety to arrays

> On Apr 13, 2017, at 5:19 AM, David Sweeris via swift-evolution > wrote: > >> >> On Apr 13, 2017, at 3:56 AM, Andrew Hart via swift-evolution >> > wrote: >> >> Recently I’ve been considering the lack of

Re: [swift-evolution] [pitch] Comparison Reform

> On Apr 13, 2017, at 2:42 PM, David Hart via swift-evolution > wrote: > > Looking good. A few comments inline: > >> On 13 Apr 2017, at 22:17, Ben Cohen via swift-evolution >> > wrote: >> Comparable >>

Re: [swift-evolution] [Review] SE-0167: Swift Encoders

here are changes to SE-0166 that affect this, we can always hold off on a decision to make more adjustments. I don’t think we need to stagger the review of two closely-related proposals like this. - Doug > > > Russ Bishop > > >> On Apr 6, 2017, at 11:10 AM, Douglas

Re: [swift-evolution] [Review #2] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

;>> John. >>> >>>> >>>> Also, in this example: >>>> >>>> let firstFriendsNameKeyPath = \Person.friends[0].name >>>> let firstFriend = luke[keyPath: firstFriendsNameKeyPath] // "Han Solo" >>>&

[swift-evolution] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

Hello Swift community, The review of SE-0169 "Improve Interaction Between private Declarations and Extensions" begins now and runs through April 11, 2017. The proposal is available here:

Re: [swift-evolution] [Review #2] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

> On Apr 6, 2017, at 1:15 PM, Michael J LeHew Jr <lehe...@apple.com> wrote: > > >> On Apr 6, 2017, at 10:37 AM, Douglas Gregor via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> >>>

[swift-evolution] [Review] SE-0166: Swift Archival & Serialization

Hello Swift community, The review of SE-0166 "Swift Archival & Serialization" begins now and runs through April 12, 2017. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0166-swift-archival-serialization.md Reviews are an important part of the

[swift-evolution] [Review] SE-0167: Swift Encoders

Hello Swift community, The review of SE-0167 "Swift Encoders" begins now and runs through April 12, 2017. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0167-swift-encoders.md Note that this proposal is closely related to (and dependent on)

Re: [swift-evolution] [Review #2] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

> On Apr 6, 2017, at 11:01 AM, Brad Hilton wrote: > > -1. Not a huge fan of the back slash. Doesn’t make sense considering we can > refer to unapplied method references without the backslash. Maybe we can > settle on some unified syntax for both? How about

Re: [swift-evolution] [Review #2] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

> On Apr 6, 2017, at 10:28 AM, Ricardo Parada wrote: > > Do you think in the future it might be possible to convert to strings? > > For example, I am imagining a CoreData-like framework on the server (where > there is no Objective-C), where I would like to get the type of

Re: [swift-evolution] [Review #2] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

> On Apr 6, 2017, at 8:13 AM, Ricardo Parada via swift-evolution > wrote: > > I agree, there's an analogy between strings and key paths, and in that > regards the single quote would make sense. I would not complain. The only analogy between strings and key-paths

Re: [swift-evolution] [Returned for revision] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

> On Apr 5, 2017, at 4:55 PM, Colin Barrett wrote: > > Is the choice of backslash up for review? I think another operator, We talked through basically everything on the keyboard, and there really aren’t other options that don’t stomp on existing behavior. >

[swift-evolution] [Review #2] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

Hello Swift community, The second review of SE-0161 "Smart KeyPaths: Better Key-Value Coding for Swift" begins now and runs through April 9, 2017. The revised proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0161-key-paths.md

[swift-evolution] [Returned for revision] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0161-key-paths.md Hello Swift community, The review of SE-0161 “Smart KeyPaths: Better Key-Value Coding for Swift” ran from March

[swift-evolution] [Review] SE-0164: Remove final support in protocol extensions

Hello Swift community, The review of SE-0164 "Remove final support in protocol extensions" begins now and runs through April 8, 2017. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0164-remove-final-support-in-protocol-extensions.md Reviews are an

Re: [swift-evolution] [Review #2] SE-0160: Limiting @objc inference

Sent from my iPhone > On Apr 5, 2017, at 1:19 AM, Víctor Pimentel wrote: > > > > Enviado desde mi iPhone > El 4 abr 2017, a las 22:04, Douglas Gregor escribió: > >> >>> On Apr 4, 2017, at 12:31 PM, Víctor Pimentel Rodríguez via swift-evolution

Re: [swift-evolution] [Review #2] SE-0160: Limiting @objc inference

> On Apr 4, 2017, at 12:31 PM, Víctor Pimentel Rodríguez via swift-evolution > wrote: > > Sorry to be late :/ > > On Fri, Mar 31, 2017 at 5:29 PM, Chris Lattner via swift-evolution > > wrote: > * What is

Re: [swift-evolution] Type-based ‘private’ access within a file

pe-based/scope-based model. * It’s the third meaning of ‘private’ in three years. However, it is unlikely to break code (one would need to construct an ambiguity between two private declarations in different extensions of the same type in the same file), and causes zero code churn, becaus

Re: [swift-evolution] Type-based ‘private’ access within a file

> On Apr 3, 2017, at 12:50 PM, David Hart wrote: > > The problem I see with that is that it would introduce orthogonal access > levels whereas they have all been hierarchal in nature up to now. Right. That was the motivation for “private” being restricted to

[swift-evolution] [Rejected] SE-0159: Fix Private Access Levels

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md The review of ran from March 20...27, 2017. The proposal has been *rejected*. The

[swift-evolution] Type-based ‘private’ access within a file

Hello Swift Community, In rejecting SE-0159 , the core team described a potential direction we would like to investigate for “private” access control that admits a limited form of type-based

Re: [swift-evolution] [Review #2] SE-0160: Limiting @objc inference

> On Apr 1, 2017, at 2:52 AM, Xiaodi Wu wrote: > > You're right, I had to re-read the proposal a few times to grasp fully the > intention there. > > There was some discussion in the previous thread that this would be needed to > infer @objc for implementations of @objc

Re: [swift-evolution] [Review #2] SE-0160: Limiting @objc inference

> On Mar 31, 2017, at 11:32 AM, David Waite via swift-evolution > wrote: > >> >> https://github.com/apple/swift-evolution/blob/master/proposals/0160-objc-inference.md >> >>

Re: [swift-evolution] [Review #2] SE-0160: Limiting @objc inference

> On Mar 31, 2017, at 9:35 AM, Xiaodi Wu via swift-evolution > wrote: > > On Fri, Mar 31, 2017 at 10:29 AM, Chris Lattner via swift-evolution > > wrote: > Hello Swift community, > > The second review of

Re: [swift-evolution] [Review] SE-0160: Limiting @objc inference

> On Mar 22, 2017, at 7:50 AM, Michel Fortin via swift-evolution > wrote: > >> * What is your evaluation of the proposal? > > Good. I'll certainly appreciate the added clarity of knowing which methods > are exposed to Objective-C. > > Currently, Swift-only apps

[swift-evolution] [Review] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

Hello Swift community, The review of SE-0161 "Smart KeyPaths: Better Key-Value Coding for Swift" begins now and runs through April 5, 2017. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0161-key-paths.md Reviews are an important part of the Swift

Re: [swift-evolution] Smart KeyPaths

Sent from my iPhone > On Mar 29, 2017, at 6:32 PM, Brent Royal-Gordon via swift-evolution > wrote: > >>> On Mar 29, 2017, at 6:21 PM, Jonathan Hull via swift-evolution >>> wrote: >>> >>> I would love it if we found a way to retain

Re: [swift-evolution] Smart KeyPaths

Sent from my iPhone > On Mar 29, 2017, at 4:52 PM, Brent Royal-Gordon > wrote: > >> On Mar 29, 2017, at 4:13 PM, Michael J LeHew Jr via swift-evolution >> wrote: >> >> Thanks for the feedback everyone! We have pushed a changed a bit ago

Re: [swift-evolution] [Review] SE-0160: Limiting @objc inference

> On Mar 23, 2017, at 2:06 AM, Slava Pestov via swift-evolution > wrote: > > Here’s an idea for working around the problem of the lack of static knowledge > during migration. Probably it’s kind of tacky and won’t get much traction in > it’s current form, but it

Re: [swift-evolution] Smart KeyPaths

> On Mar 17, 2017, at 10:04 AM, Michael LeHew via swift-evolution > wrote: > > Hi friendly swift-evolution folks, > > The Foundation and Swift team would like for you to consider the following > proposal: The Swift core team discussed this proposal draft and had

Re: [swift-evolution] [Review] SE-0160: Limiting @objc inference

> On Mar 25, 2017, at 3:46 PM, Brent Royal-Gordon > wrote: > >> On Mar 24, 2017, at 10:09 AM, Douglas Gregor wrote: >> >>> I'm actually not worried about methods so much as properties. KVC is >>> completely untyped on the Objective-C side, and

Re: [swift-evolution] [Review] SE-0160: Limiting @objc inference

> On Mar 26, 2017, at 8:23 PM, Charlie Monroe wrote: > >> >> On Mar 25, 2017, at 11:46 PM, Brent Royal-Gordon via swift-evolution >> wrote: >> >>> On Mar 24, 2017, at 10:09 AM, Douglas Gregor wrote: >>> Plus,

Re: [swift-evolution] [Review] SE-0160: Limiting @objc inference

> On Mar 22, 2017, at 10:55 PM, Brent Royal-Gordon via swift-evolution > wrote: > >> On Mar 21, 2017, at 11:03 PM, Chris Lattner via swift-evolution >> wrote: >> >> * What is your evaluation of the proposal? > > I'm going to have to

  1   2   3   4   5   >