Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

Sent from my iPad > On Mar 23, 2017, at 9:48 PM, Charles Srstka wrote: > >> On Mar 23, 2017, at 8:35 PM, Matthew Johnson via swift-evolution >> wrote: >> >> On Mar 23, 2017, at 8:27 PM, Drew Crawford wrote: >> >>> >>> >>>

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

Sent from my iPad > On Mar 23, 2017, at 8:27 PM, Drew Crawford wrote: > > > > > Sent from my iPhone > On Mar 23, 2017, at 6:41 PM, David Hart wrote: > >> I have difficulties imagining a submodule proposal that could allow us to >> eliminate fileprivate. Care to give an example? > > The

Re: [swift-evolution] Pitch: Partial Implementations

Sent from my iPhone > On Mar 23, 2017, at 2:47 PM, Charles Srstka wrote: > >> On Mar 23, 2017, at 2:45 PM, Matthew Johnson wrote: >> >> Sure, but this does effectively violate lexical scope boundaries as they >> exist in the original source. > > If the yeas have it on SE-0159, and “private

Re: [swift-evolution] Pitch: Partial Implementations

> On Mar 23, 2017, at 2:37 PM, Charles Srstka wrote: > >> On Mar 23, 2017, at 2:15 PM, Matthew Johnson > > wrote: >> >> What I’m suggesting is that we could accomplish the same functionality by >> enhancing extensions. You can make a case that using a different

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

> On Mar 23, 2017, at 2:02 PM, David Hart via swift-evolution > wrote: > > > > On 23 Mar 2017, at 16:49, Drew Crawford > wrote: > >> >> >> >> On March 23, 2017 at 2:22:20 AM, David Hart (da...@hartbit.com >> ) wrote: >> >>> > We

Re: [swift-evolution] Pitch: Partial Implementations

> On Mar 23, 2017, at 2:04 PM, Charles Srstka wrote: > >> On Mar 23, 2017, at 1:21 PM, Matthew Johnson > > wrote: >> >> If we wanted to allow code like this to be written we wouldn’t need a new >> keyword to do it. You are proposing two things here: >> >> 1) Al

Re: [swift-evolution] Pitch: Partial Implementations

> On Mar 23, 2017, at 1:12 PM, Charles Srstka via swift-evolution > wrote: > > MOTIVATION: > > In current Swift, a pattern has emerged among some developers, in order to > logically group parts of a class or struct’s declaration, particularly around > protocols: > > class Foo { > … >

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

> On Mar 23, 2017, at 10:54 AM, Zach Waldowski via swift-evolution > wrote: > > >> On Mar 23, 2017, at 2:22 AM, Matt Gallagher via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> I can't help but feel that this proposal is really misdirected frustration. >> Programmers who do

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

> On Mar 23, 2017, at 10:51 AM, Andrey Fidrya via swift-evolution > wrote: > >> On 23 Mar 2017, at 05:18, Nevin Brackett-Rozinsky via swift-evolution >> wrote: >> I strongly prefer that “private” should mean “visible in the current file”. >> I am ambivalent between eliminating the scoped acce

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

> On Mar 23, 2017, at 1:22 AM, Matt Gallagher via swift-evolution > wrote: > >> What is your evaluation of the proposal? > > I disagree with this proposal. It removes functionality that I actively use. > > This proposal aims to revert SE-0025 without really addressing the aims of > that prop

Re: [swift-evolution] Smart KeyPaths

> On Mar 22, 2017, at 3:30 PM, Brent Royal-Gordon > wrote: > >> On Mar 22, 2017, at 11:27 AM, Matthew Johnson via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> One option would be to include `get` and `set` methods on the key path

Re: [swift-evolution] Smart KeyPaths

> On Mar 22, 2017, at 12:34 PM, Vladimir.S wrote: > > On 22.03.2017 19:25, Matthew Johnson wrote: >> >>> On Mar 22, 2017, at 11:00 AM, Vladimir.S >> > wrote: >>> >>> On 22.03.2017 18:47, Matthew Johnson wrote: > On Mar 22, 2017, at 10:36 AM, Vladimir.S via sw

Re: [swift-evolution] Swift null safety questions

> On Mar 22, 2017, at 12:03 PM, Joe Groff via swift-evolution > wrote: > > >> On Mar 6, 2017, at 4:20 PM, Elijah Johnson via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> Hi, >> >> I’ve been recently considering Swift on the server-side, and there came up >> the questi

Re: [swift-evolution] Smart KeyPaths

> On Mar 22, 2017, at 11:41 AM, Ricardo Parada wrote: > > Agree. > > Another question. If `Bag` does have a static thing called `myStaticThingy` > would you refer to it as: > > Bag.Type#myStaticThingy I would expect that to work eventually but I’m not sure if it would be included in the in

Re: [swift-evolution] Smart KeyPaths

> On Mar 22, 2017, at 11:16 AM, Ricardo Parada wrote: > > I see three possibilities: > > 1) # + «space» +«path» like this: > > let path = # Bag.things[0].name > bag[path] > bag[# Bag.things[0].name] > bag[# .things[0].name] // Root is inferred as Bag > bag.things[0][# Thing.name] > bag.thing

Re: [swift-evolution] Smart KeyPaths

> On Mar 22, 2017, at 11:00 AM, Vladimir.S wrote: > > On 22.03.2017 18:47, Matthew Johnson wrote: >> >>> On Mar 22, 2017, at 10:36 AM, Vladimir.S via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> >>> On 22.03.2017 17:37, Ricardo Parada wrote: > On Mar 22, 20

Re: [swift-evolution] Smart KeyPaths

> On Mar 22, 2017, at 10:36 AM, Vladimir.S via swift-evolution > wrote: > > On 22.03.2017 17:37, Ricardo Parada wrote: >> >> >>> On Mar 22, 2017, at 9:30 AM, Vladimir.S wrote: >>> >>> let path = @Bag.things[0].name >>> >>> bag@path >>> bag@.things[0].name >>> bag@Bag.things[0].name >>> bag

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

> * What is your evaluation of the proposal? +1. This clarifies the interaction between Swift and Objective-C and reduces the magic that exists for bridging. It’s one more step on the road of Swift relying less on the Objective-C runtime - decoupling the semantics of `dynamic` from `@objc` i

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

> On Mar 21, 2017, at 10:02 PM, Xiaodi Wu wrote: > > On Tue, Mar 21, 2017 at 9:32 PM, Matthew Johnson > wrote: > >> On Mar 21, 2017, at 9:17 PM, Xiaodi Wu via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> On Tue, Mar 21, 2017 at 8:31 PM, Ch

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

> On Mar 21, 2017, at 9:17 PM, Xiaodi Wu via swift-evolution > wrote: > > On Tue, Mar 21, 2017 at 8:31 PM, Charles Srstka > wrote: > >> On Mar 21, 2017, at 8:15 PM, Xiaodi Wu > > wrote: >> >> On Tue, Mar 21, 2017 at 8:00 PM, Charle

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

Sent from my iPad > On Mar 21, 2017, at 7:40 PM, Xiaodi Wu via swift-evolution > wrote: > >> On Tue, Mar 21, 2017 at 6:44 PM, Drew Crawford >> wrote: I am confused by this response. An argument in _support_ of new `private` was that it is more in line with expectations of users c

Re: [swift-evolution] Smart KeyPaths

Sent from my iPad > On Mar 21, 2017, at 8:00 PM, Ben Rimmington wrote: > > Re: > >> On 21 Mar 2017, at 13:16, Matthew Johnson wrote: >> >> I think the language is best served if all unbound members are accessible >> using the same syntax.

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

Sent from my iPhone > On Mar 21, 2017, at 4:48 PM, Jose Cheyo Jimenez wrote: > > >>> On Mar 21, 2017, at 2:33 PM, Matthew Johnson wrote: >>> >>> >>>> On Mar 21, 2017, at 4:26 PM, Jose Cheyo Jimenez >>>> wrote: >>>&

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

> On Mar 21, 2017, at 4:26 PM, Jose Cheyo Jimenez wrote: > > >> On Mar 21, 2017, at 11:54 AM, Matthew Johnson via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> >>> On Mar 21, 2017, at 1:41 PM, David Hart via swift-evoluti

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

> On Mar 21, 2017, at 1:41 PM, David Hart via swift-evolution > wrote: > > > > > > Sent from my iPhone > On 21 Mar 2017, at 16:57, Drew Crawford > wrote: > >> >> >>> > I’m not arguing that it is less or more than a majority. I’m just saying >>> > that we

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

> On Mar 21, 2017, at 11:24 AM, Colin Barrett > wrote: > > I'm not sure I follow. What do you mean "which strategy to use for a given > encoding"? IMO there should be at most one implementation of Coding / > Decoding for a particular type. So the way you'd say "I want to decode a JSON > resp

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

> On Mar 21, 2017, at 11:00 AM, Colin Barrett via swift-evolution > wrote: > > > > On Thu, Mar 16, 2017 at 3:33 PM Itai Ferber via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > > Here's what I mean: Suppose I have a BlogPost model, and I can both fetch and > post BlogPosts

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

> On Mar 21, 2017, at 10:57 AM, Drew Crawford via swift-evolution > wrote: > > > >> > I’m not arguing that it is less or more than a majority. I’m just saying >> > that we’ve seen a lot of talk against the original change. > > This proposal asks us to balance the convenience of one group >

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

> On Mar 20, 2017, at 9:33 PM, Greg Parker via swift-evolution > wrote: > > >> On Mar 20, 2017, at 4:54 PM, Douglas Gregor > > wrote: >> >> Hello Swift community, >> >> The review of SE-0159 "Fix Private Access Levels" begins now and runs >> through March 27, 2017.

Re: [swift-evolution] Smart KeyPaths

Sent from my iPad > On Mar 21, 2017, at 7:27 AM, Jean-Daniel wrote: > > >>> Le 20 mars 2017 à 15:52, Matthew Johnson via swift-evolution >>> a écrit : >>> >>> >>> On Mar 20, 2017, at 9:23 AM, Christopher Kornher via swift-evolution

Re: [swift-evolution] Fwd: Re: Smart KeyPaths

> On Mar 20, 2017, at 12:37 PM, Vladimir.S via swift-evolution > wrote: > > On 20.03.2017 17:56, Charles Srstka via swift-evolution wrote: >>> On Mar 20, 2017, at 9:23 AM, Christopher Kornher via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> On Mar 20, 2017, at 5:12 AM

Re: [swift-evolution] Smart KeyPaths

uct keypath { >>>> >>>> static let name = #keyPath(Person.name) >>>> … >>>> } >>>> >>>> … >>>> } >>>> >>>> where a keypath is then used like this: >>>> >>>> Person

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

> On Mar 20, 2017, at 5:34 AM, Brent Royal-Gordon > wrote: > >> On Mar 19, 2017, at 8:19 PM, Matthew Johnson > > wrote: >> >> First, your solution does not allow a user to see a context if they can't >> name the type (you can't get it as Any and use reflection,

Re: [swift-evolution] Smart KeyPaths

;>>> } >>>> >>>> … >>>> } >>>> >>>> where a keypath is then used like this: >>>> >>>> Person.keypath.name >>>> >>>> and this has worked very well. It makes it easy to see where w

Re: [swift-evolution] Smart KeyPaths

Sent from my iPad > On Mar 19, 2017, at 11:02 PM, jaden.gel...@gmail.com wrote: > > You mean overloaded, not shadowed, right? No. What I mean by shadowed is this: struct Foo { // you write this: let bar: Int // compiler automatically synthesizes a static keypath: static let b

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

Sent from my iPad > On Mar 20, 2017, at 1:43 AM, David Hart wrote: > > >> On 20 Mar 2017, at 02:09, Matthew Johnson via swift-evolution >> wrote: >> >> >>>> On Mar 19, 2017, at 2:21 PM, Tony Parker wrote: >>>> >>>

Re: [swift-evolution] Smart KeyPaths

Sent from my iPad > On Mar 19, 2017, at 10:31 PM, Jaden Geller via swift-evolution > wrote: > > I think the clarity desired is more similar to that obtained by the `try` > keyword. Ya, the compiler knows that this function throws already, but Swift > aims for clarity in the source code. Cla

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

Sent from my iPad > On Mar 19, 2017, at 10:19 PM, Matthew Johnson via swift-evolution > wrote: > > > > Sent from my iPad > >> On Mar 19, 2017, at 9:14 PM, Brent Royal-Gordon >> wrote: >> >>> On Mar 19, 2017, at 5:51 PM, Matthew Johnson

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

Sent from my iPad > On Mar 19, 2017, at 9:14 PM, Brent Royal-Gordon > wrote: > >> On Mar 19, 2017, at 5:51 PM, Matthew Johnson wrote: >> >> I generally agree with you about casting. However, my dislike isn’t the >> cast itself, but instead it is the lack of a static guarantee. I’m not su

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

oing to give a little bit of thought to this but don’t expect to come up with a good answer. At least one hurdle to this in the current proposal is that the Foundation encoders and decoders hide the types that actually do the encoding and decoding. There are probably very good reasons for this

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

> On Mar 19, 2017, at 3:38 PM, Brent Royal-Gordon > wrote: > >> On Mar 19, 2017, at 12:21 PM, Tony Parker > > wrote: >>> >>> On Mar 19, 2017, at 12:14 PM, Matthew Johnson >> > wrote: >>> >>> On Mar 19, 2017, at 10:47 AM, Tony Par

Re: [swift-evolution] Smart KeyPaths

Sent from my iPhone > On Mar 19, 2017, at 4:02 PM, Charles Srstka via swift-evolution > wrote: > >>> On Mar 19, 2017, at 3:45 PM, Brent Royal-Gordon >>> wrote: >>> On Mar 19, 2017, at 12:57 PM, Charles Srstka via swift-evolution wrote: I disagree. How the reader is s

Re: [swift-evolution] Smart KeyPaths

Sent from my iPhone > On Mar 19, 2017, at 3:45 PM, Brent Royal-Gordon via swift-evolution > wrote: > >>> On Mar 19, 2017, at 12:57 PM, Charles Srstka via swift-evolution >>> wrote: >>> >>> I disagree. How the reader is supposed to now there is a static property or >>> not ? Having readabl

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

ypes receive the context they need to encode / decode correctly. I much prefer the static safety but having a solution is better than not having one. :) > > - Tony > >>> On Mar 17, 2017, at 5:56 PM, Matthew Johnson via swift-evolution >>> wrote: >>> >&

Re: [swift-evolution] Smart KeyPaths

> On Mar 17, 2017, at 5:38 PM, Joe Groff via swift-evolution > wrote: > > >> On Mar 17, 2017, at 12:34 PM, David Hart via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> Sent off-list by mistake: >> >> Nice proposal. I have a few comments inline: >> >>> On 17 Mar 2017, a

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

> On Mar 17, 2017, at 6:15 PM, Brent Royal-Gordon > wrote: > >> On Mar 17, 2017, at 3:35 PM, Matthew Johnson > > wrote: >> >>> In all seriousness, I see the design as very slightly weak, in that it >>> makes it easy to forget to pass a context through, but quite

Re: [swift-evolution] Smart KeyPaths

> On Mar 17, 2017, at 6:29 PM, Joe Groff wrote: > > >> On Mar 17, 2017, at 4:25 PM, Matthew Johnson > > wrote: >> >> >> >> Sent from my iPhone >> >> On Mar 17, 2017, at 6:09 PM, Joe Groff > > wrote: >> >>> On Mar 17, 2017, at 4:

Re: [swift-evolution] Smart KeyPaths

Sent from my iPhone > On Mar 17, 2017, at 6:09 PM, Joe Groff wrote: > > >> On Mar 17, 2017, at 4:05 PM, Matthew Johnson wrote: >> >> >> >> Sent from my iPad >> >>> On Mar 17, 2017, at 5:38 PM, Joe Groff via swift-evolution >>> wrote: >>> >>> On Mar 17, 2017, at 12:34 PM, David H

Re: [swift-evolution] Smart KeyPaths

Sent from my iPad > On Mar 17, 2017, at 5:38 PM, Joe Groff via swift-evolution > wrote: > > >> On Mar 17, 2017, at 12:34 PM, David Hart via swift-evolution >> wrote: >> >> Sent off-list by mistake: >> >> Nice proposal. I have a few comments inline: >> >>> On 17 Mar 2017, at 18:04, Micha

Re: [swift-evolution] Smart KeyPaths

Sent from my iPad > On Mar 17, 2017, at 5:45 PM, Joe Groff wrote: > > >>> On Mar 17, 2017, at 3:08 PM, Matthew Johnson via swift-evolution >>> wrote: >>> >>> >>> On Mar 17, 2017, at 12:04 PM, Michael LeHew via swift-evolution

Re: [swift-evolution] Smart KeyPaths

Sent from my iPad > On Mar 17, 2017, at 5:24 PM, Brent Royal-Gordon > wrote: > >> On Mar 17, 2017, at 3:17 PM, Michael LeHew via swift-evolution >> wrote: >> >> One thing that gets interesting with the scope-restricted visibility of >> KeyPaths, is what happens if an fileprivate KeyPath g

Re: [swift-evolution] Smart KeyPaths

Sent from my iPad > On Mar 17, 2017, at 5:17 PM, Michael LeHew wrote: > > >>> On Mar 17, 2017, at 3:08 PM, Matthew Johnson wrote: >>> >>> >>> On Mar 17, 2017, at 12:04 PM, Michael LeHew via swift-evolution >>> wrote: >>> >>> Hi friendly swift-evolution folks, >>> >>> The Foundation and

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

> On Mar 17, 2017, at 5:13 PM, Brent Royal-Gordon > wrote: > >> On Mar 17, 2017, at 2:38 PM, Matthew Johnson > > wrote: >> >>> At a broad level, that's a good idea. But why not provide something more >>> precise than a bag of `Any`s here? You're in pure Swift; y

Re: [swift-evolution] Smart KeyPaths

> On Mar 17, 2017, at 12:04 PM, 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: This proposal is really incredible! It is an invaluable addition to the language - f

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

Sent from my iPhone > On Mar 17, 2017, at 3:36 PM, Joe Groff via swift-evolution > wrote: > > >> On Mar 17, 2017, at 12:49 PM, Itai Ferber wrote: >> >> On 17 Mar 2017, at 12:18, Michael Gottesman wrote: >> >> >> On Mar 16, 2017, at 10:23 AM, Joe Groff via swift-evolution >> wrote: >>

Re: [swift-evolution] Swift's reflection

> On Mar 17, 2017, at 3:42 PM, Joe Groff via swift-evolution > wrote: > > I hope that Mirror will ultimately be superseded by key paths: > > https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170313/033998.html > >

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

> On Mar 17, 2017, at 3:23 PM, Brent Royal-Gordon via swift-evolution > wrote: > >> On Mar 16, 2017, at 12:33 PM, Itai Ferber > > wrote: >> Optional values are accepted and vended directly through the API. The >> encode(_:forKey:) methods take optional values directly

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

> On Mar 17, 2017, at 2:42 PM, Itai Ferber wrote: > > On 16 Mar 2017, at 14:29, Matthew Johnson wrote: > > > This is a fantastic proposal! I am very much looking forward to robust > Swift-native encoding and decoding in Foundation. The compiler synthesized > conformances is especially great!

Re: [swift-evolution] Smart KeyPaths

> On Mar 17, 2017, at 2:34 PM, David Hart via swift-evolution > wrote: > > Sent off-list by mistake: > > Nice proposal. I have a few comments inline: > >> On 17 Mar 2017, at 18:04, Michael LeHew via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> Hi friendly swift-evoluti

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

> On Mar 17, 2017, at 1:15 PM, Itai Ferber via swift-evolution > wrote: > > On 15 Mar 2017, at 22:58, Zach Waldowski wrote: > > > Another issue of scale - I had to switch to a native mail client as replying > inline severely broke my webmail client. ;-) > > Again, lots of love here. Respons

Re: [swift-evolution] [Proposal] Foundation Swift Encoders

Sent from my iPad > On Mar 16, 2017, at 5:59 PM, Itai Ferber wrote: > > On 16 Mar 2017, at 15:45, Matthew Johnson wrote: > > > On Mar 16, 2017, at 5:37 PM, Itai Ferber wrote: > > On 16 Mar 2017, at 14:48, Matthew Johnson wrote: > > Thank you again for bringing these great proposals forward

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

Sent from my iPad > On Mar 16, 2017, at 5:54 PM, Ben Rimmington wrote: > > >>> On 16 Mar 2017, at 21:14, Matthew Johnson wrote: >>> >>> On Mar 16, 2017, at 4:12 PM, Itai Ferber wrote: >>> >>> If throwing subscripts made it in the Swift 4 timeframe, then we would >>> certainly consider it.

Re: [swift-evolution] [Proposal] Foundation Swift Encoders

> On Mar 16, 2017, at 5:37 PM, Itai Ferber wrote: > > On 16 Mar 2017, at 14:48, Matthew Johnson wrote: > > Thank you again for bringing these great proposals forward! > > Thanks for reviewing it, and for your comments! > > I only have a couple of questions about this proposal. > > I noticed

Re: [swift-evolution] [Proposal] Foundation Swift Encoders

Thank you again for bringing these great proposals forward! I only have a couple of questions about this proposal. I noticed that the types in this proposal don’t conform to Encoder and Decoder. Is the plan to have them to provide private conforming types to Codable types they are asked to enc

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

This is a fantastic proposal! I am very much looking forward to robust Swift-native encoding and decoding in Foundation. The compiler synthesized conformances is especially great!I want to thank everyone who worked on it. It is clear that a lot of work went into the proposal. The proposa

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

in incremental > migration. Yes, probably so. I would be disappointed if we allowed the design of Swift 4 features to be influenced by Swift 3.1 compatibility. > >> On Mar 16, 2017, at 2:14 PM, Matthew Johnson via swift-evolution >> mailto:swift-evolution@swift.org>> wrot

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

hrowing subscripts into Swift 4, why not use Swift’s first > class syntactic support for keyed access to keyed containers? > >> On 16 Mar 2017, at 11:46, Matthew Johnson via swift-evolution wrote: >> >> >> >>> On Mar 16, 2017, at 1:34 PM, Zach Waldow

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

hem is a disservice to the community. It’s hard to say if that will happen in this case but I suspect it might. I know writing one is the first thing I would do if this proposal is accepted as-is and I suspect many other people would feel the same way. >> The ambiguity in the general c

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

> On Mar 16, 2017, at 3:27 PM, Tony Parker wrote: > > >> On Mar 16, 2017, at 1:24 PM, Matthew Johnson via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >>> >>> On Mar 16, 2017, at 2:58 PM, David Hart via swift-evol

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

> On Mar 16, 2017, at 2:58 PM, David Hart via swift-evolution > wrote: > > >> On 16 Mar 2017, at 19:34, Zach Waldowski via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> On Thu, Mar 16, 2017, at 02:23 PM, Matthew Johnson via

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

he Swift 4 timeframe. If not, then yes we need a method rather than a subscript. But if we can get throwing subscripts into Swift 4, why not use Swift’s first class syntactic support for keyed access to keyed containers? > On 16 Mar 2017, at 11:46, Matthew Johnson via swift-evolution wrote:

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

> On Mar 16, 2017, at 1:34 PM, Zach Waldowski via swift-evolution > wrote: > > On Thu, Mar 16, 2017, at 02:23 PM, Matthew Johnson via swift-evolution wrote: >> I don’t have an example but I don’t see a problem either. There are two >> options for specifying the retur

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

> On Mar 16, 2017, at 1:06 PM, David Hart via swift-evolution > wrote: > > > On 16 Mar 2017, at 16:53, Zach Waldowski > wrote: > >>> On Mar 16, 2017, at 3:09 AM, David Hart via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> >>> 2) Libraries like

Re: [swift-evolution] Swift null safety questions

Sent from my iPad On Mar 13, 2017, at 6:35 PM, Brent Royal-Gordon via swift-evolution wrote: >> On Mar 12, 2017, at 12:20 PM, Austin Zheng via swift-evolution >> wrote: >> >> Otherwise, if you really need to build a web server framework that can >> swallow any sort of application logic wi

Re: [swift-evolution] [Idea] Generic associated types

> On Mar 13, 2017, at 11:50 AM, John McCall wrote: > >> On Mar 12, 2017, at 5:00 PM, Matthew Johnson via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >>> On Mar 12, 2017, at 3:23 PM, Karl Wagner >> <mailto:razie...@gmail.com>>

Re: [swift-evolution] [Idea] Generic associated types

> On Mar 12, 2017, at 3:23 PM, Karl Wagner wrote: > > >> On 12 Mar 2017, at 14:32, Matthew Johnson > > wrote: >> >> This is a really important feature IMO, but as others have pointed out it >> basically amounts to higher-kinded types. I would love to be wrong a

Re: [swift-evolution] [Idea] Generic associated types

This is a really important feature IMO, but as others have pointed out it basically amounts to higher-kinded types. I would love to be wrong about this but I am reasonably sure this is out of scope for Swift 4 (otherwise I would be working on a proposal already). Sent from my iPad > On Mar 11

Re: [swift-evolution] [Draft] Anonymous Enum Cases

+1. Combining this with overloaded cases will be very nice for some kinds of enums. Sent from my iPad > On Mar 8, 2017, at 9:09 PM, Daniel Duan via swift-evolution > wrote: > > Hi all, > > During review for the first revision of SE-0155, Dave Abraham suggested that > we should allow enum c

Re: [swift-evolution] Normalize Enum Case Representation (rev. 2)

Sent from my iPad > On Mar 9, 2017, at 2:31 AM, Xiaodi Wu via swift-evolution > wrote: > >> On Thu, Mar 9, 2017 at 1:07 AM, Daniel Duan wrote: >> Thanks for the thoughtful feed Xiaodi! Replies are inline. I'm going to >> incorporate some of the responses into the proposal. >> >>> On Mar 8,

Re: [swift-evolution] [Draft] Remove support for final in protocol extensions

Sent from my iPad > On Mar 9, 2017, at 2:23 AM, Slava Pestov via swift-evolution > wrote: > > I think the fact that the type checker permits ‘final’ to appear inside > protocol extensions is an oversight and this probably does not even warrant a > proposal. I don’t think allowing this was e

Re: [swift-evolution] [Draft] Really Simple Submodules

Sent from my iPad > On Mar 6, 2017, at 1:39 AM, Robert Widmann via swift-evolution > wrote: > > If this were a problem that could be fixed by tooling, you'd be submitting > this proposal against the package manager. > > It's important to note I'm approaching this problem from the principles

Re: [swift-evolution] Yet Another Take on Swift Sub-modules

> On Mar 5, 2017, at 1:29 PM, Karim Nassar via swift-evolution > wrote: > > > >> On Mar 5, 2017, at 2:06 PM, Xiaodi Wu > > wrote: >> >> Punycode would readily cover your first issue about legal identifier >> characters. > > Well, it would cover… I’m not sure if

Re: [swift-evolution] Yet Another Take on Swift Sub-modules

> On Mar 5, 2017, at 1:06 PM, Xiaodi Wu via swift-evolution > wrote: > > Punycode would readily cover your first issue about legal identifier > characters. > > As to the second, having enumerated the essential properties of a Foo, what > "growth" are you envisioning? I am working on an upda

Re: [swift-evolution] Should explicit `self.` be required when providing method as closure?

> On Mar 5, 2017, at 11:12 AM, Daniel Leping via swift-evolution > wrote: > > I'm not proposing syntax right now. Rather approach. Should we make ANY > capturing explicit? I don't know. Maybe someone has a stronger opinion here. I think that would be way too verbose. Perhaps you mean all *re

Re: [swift-evolution] Yet Another Take on Swift Sub-modules

> On Mar 5, 2017, at 9:10 AM, Rien wrote: > > >> On 05 Mar 2017, at 15:52, Karim Nassar via swift-evolution >> wrote: >> >> >>> On Mar 4, 2017, at 2:54 PM, Matthew Johnson wrote: >>> On Mar 4, 2017, at 9:56 AM, Karim Nassar wrote: > On Mar 3, 2017, at 5:21 PM,

Re: [swift-evolution] Yet Another Take on Swift Sub-modules

> On Mar 5, 2017, at 8:52 AM, Karim Nassar wrote: > > >> On Mar 4, 2017, at 2:54 PM, Matthew Johnson > > wrote: >> >>> >>> On Mar 4, 2017, at 9:56 AM, Karim Nassar >> > wrote: >>> >>> On Mar 3, 2017, at 5:21 PM, Matthew Johns

Re: [swift-evolution] [Draft] A Consistent Foundation For Access Control: Scope-Bounded Capabilities

-- > Adrian Zubarev > Sent with Airmail > > Am 4. März 2017 um 20:10:56, Matthew Johnson via swift-evolution > (swift-evolution@swift.org) schrieb: > >> >> >> Sent from my iPad >> >> > On Mar 4, 2017, at 10:09 AM, Rien wrote: >> >

Re: [swift-evolution] Yet Another Take on Swift Sub-modules

> On Mar 4, 2017, at 9:56 AM, Karim Nassar wrote: > > >> On Mar 3, 2017, at 5:21 PM, Matthew Johnson > > wrote: >> >>> >>> On Mar 3, 2017, at 9:24 AM, Karim Nassar via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> >>> Changes that *are* nec

Re: [swift-evolution] Should explicit `self.` be required when providing method as closure?

Sent from my iPad > On Mar 4, 2017, at 11:35 AM, Charles Srstka via swift-evolution > wrote: > >> On Mar 4, 2017, at 1:09 AM, David Hart via swift-evolution >> wrote: >> >> I encountered this precise memory leak in my code a few days ago, so I >> sympathize. A second solution would be to

Re: [swift-evolution] [Draft] A Consistent Foundation For Access Control: Scope-Bounded Capabilities

Sent from my iPad > On Mar 4, 2017, at 10:09 AM, Rien wrote: > > >> On 04 Mar 2017, at 16:01, Matthew Johnson via swift-evolution >> wrote: >> >> I have updated this proposal with a few more refinements based on >> yesterday’s discussion. Yo

Re: [swift-evolution] Yet Another Take on Swift Sub-modules

> On Mar 4, 2017, at 8:12 AM, Jean-Daniel wrote: > >> >> Le 3 mars 2017 à 23:21, Matthew Johnson via swift-evolution >> mailto:swift-evolution@swift.org>> a écrit : >> >>> >>> On Mar 3, 2017, at 9:24 AM, Karim Nassar via swift-e

Re: [swift-evolution] Yet Another Take on Swift Sub-modules

> On Mar 3, 2017, at 9:24 AM, Karim Nassar via swift-evolution > wrote: > > > I’ve read through the last couple of Swift (sub)Module proposals put forward, > and since my particular use-cases for a sub-module solution seemed to be > under-served by them, I’ve decided to write up my thoughts

Re: [swift-evolution] [Proposal][Discussion] Modular Swift

ndaries larger than a file but smaller than a module? > > > > > On Thu, Mar 2, 2017 at 11:01 PM, Matthew Johnson <mailto:matt...@anandabits.com>> wrote: > > > Sent from my iPad > > On Mar 2, 2017, at 9:06 PM, T.J. Usiyan <mailto:griotsp...@gmail.com>> w

Re: [swift-evolution] [Draft] scope-based submodules

> On Mar 2, 2017, at 10:08 PM, Brent Royal-Gordon > wrote: > >> On Mar 1, 2017, at 11:56 AM, David Hart wrote: >> >>> 2. Normally, references within the module to submodule symbols need to be >>> prefixed with the submodule name. (That is, in top-level `Foo` code, you >>> need to write `Bar

Re: [swift-evolution] [Draft] A Consistent Foundation For Access Control: Scope-Bounded Capabilities

> On Mar 3, 2017, at 1:26 PM, Adrian Zubarev > wrote: > > Can you check this translation, and maybe based on it’s (possible) mistakes > provide better examples in the next proposal draft on how one should think > with the new pure access model. > > open class A { > > open internal(

Re: [swift-evolution] [Draft] A Consistent Foundation For Access Control: Scope-Bounded Capabilities

ia swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> General impression is positive in case shortcuts (private, bulblic) still >> remain for the most common use cases. >> >> On Thu, 2 Mar 2017 at 21:58 Matthew Johnson via swift-evolutio

Re: [swift-evolution] [Draft] A Consistent Foundation For Access Control: Scope-Bounded Capabilities

> On Mar 3, 2017, at 1:12 PM, Adrian Zubarev > wrote: > > If I understand the model correctly, then classes structs and enums will have > an addition capability for their members. > > static = access(type) access(override, nowhere) > > class = access(type) access(override, everywhere) > > Y

Re: [swift-evolution] [Draft] A Consistent Foundation For Access Control: Scope-Bounded Capabilities

On Thu, 2 Mar 2017 at 21:58 Matthew Johnson via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > I’ve been continuing to think about how to provide clear and consistent > semantics for access control in Swift. This draft represents what I think is > the best way to

Re: [swift-evolution] [Draft] A Consistent Foundation For Access Control: Scope-Bounded Capabilities

/Balancingrock > Project: http://swiftfire.nl > > > > > >> On 02 Mar 2017, at 20:58, Matthew Johnson via swift-evolution >> wrote: >> >> I’ve been continuing to think about how to provide clear and consistent >> semantics for access control in Swif

Re: [swift-evolution] [Draft] A Consistent Foundation For Access Control: Scope-Bounded Capabilities

> On Mar 3, 2017, at 3:19 AM, Adrian Zubarev via swift-evolution > wrote: > > (1) It seems odd to use scope as both an access control modifier alone and as > a function-like attribute. Perhaps something like access(set, scope) would be > better than scope(set). As it is, we’re conflating scop

<    1   2   3   4   5   6   7   8   9   10   >