Re: [swift-evolution] [Pitch] Cross-platform Swift TLS library

I subscribed to the list, thanks. I guess security is something people “want to look into later”… and then somehow never get to it. Regards, Rien Site: http://balancingrock.nl Blog: http://swiftrien.blogspot.com Github: http://github.com/Balancingrock Project: http://swiftfire.nl - A server

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

-1 for reasons I've previously expressed in the discussions: - It encourages everything to be stuffed in one file. - It doesn't actually solve anything as the new private is very close to fileprivate, while abolishing private as truly scoped - which is a tool I use on regular basis. Simply as

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

> On Apr 6, 2017, at 9:46 PM, John McCall wrote: > >> On Apr 7, 2017, at 12:27 AM, Rick Mann wrote: >>> On Apr 6, 2017, at 20:37 , John McCall wrote: >>> On Apr 6, 2017, at 9:28 PM, Rick Mann via swift-evolution

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

> On Apr 7, 2017, at 12:27 AM, Rick Mann wrote: >> On Apr 6, 2017, at 20:37 , John McCall wrote: >> >>> On Apr 6, 2017, at 9:28 PM, Rick Mann via swift-evolution >>> wrote: >>> I tend to dislike the backslash as well, but

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

> On Apr 7, 2017, at 2:38 AM, Charles Srstka via swift-evolution > wrote: > >> On Apr 6, 2017, at 7:34 PM, Xiaodi Wu via swift-evolution >> > wrote: >> >> `private` works for extensions exactly how the

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

> On Apr 6, 2017, at 20:37 , John McCall wrote: > >> On Apr 6, 2017, at 9:28 PM, Rick Mann via swift-evolution >> wrote: >> I tend to dislike the backslash as well, but can't suggest a good >> alternative. >> >> Does any of this allow for

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

> On Apr 5, 2017, at 7:56 PM, Douglas Gregor wrote: > > 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: > >

Re: [swift-evolution] [swift-evolution-announce] [Review] 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 > What is your evaluation of the proposal? I don't understand the need for this: when you need things to be accessible elsewhere in the file

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

> On Apr 6, 2017, at 9:28 PM, Rick Mann via swift-evolution > wrote: > I tend to dislike the backslash as well, but can't suggest a good alternative. > > Does any of this allow for operations within the key path? e.g. > Department.employees.@sum.salary? You can

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

This use case has at least been brought up in discussions within my team. I wouldn't be surprised if it's actually deployed as well. Given a big project with enough experienced devs, I'd say this pattern is almost a certainty. Daniel Duan Sent from my iPhone > On Apr 6, 2017, at 6:53 PM, Brent

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

Proposal link: https://github.com/apple/swift-evolution/blob/master/proposals/0160-objc-inference.md The re-review of SE-0160 ran from March 31...April 2. The proposal is accepted. The feedback on the second round of review was very light and uniformly positive. The proposal has been

[swift-evolution] [Review] SE-0168: Multi-Line String Literals

• What is your evaluation of the proposal? -0.1 • Is the problem being addressed significant enough to warrant a change to Swift? Yes • Does this proposal fit well with the feel and direction of Swift? I don't think so. While Python's way of doing multiline strings may work for Python, I

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

Yes, it is a hypothetical short head, not part of this proposal or any existing proposal currently. But it kind of fits. -Michael > On Apr 6, 2017, at 6:21 PM, Ricardo Parada wrote: > > Hi, > > I am trying to follow the emails. Would that be same as KeyPath >

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

> On Apr 6, 2017, at 5:38 PM, Charles Srstka via swift-evolution > wrote: > >> On Apr 6, 2017, at 7:34 PM, Xiaodi Wu via swift-evolution >> > wrote: >> >> `private` works for extensions exactly how the

Re: [swift-evolution] SE-165: Dictionary & Set Enhancements

How important is it that the closure be allowed to throw when resolving collisions? In my use cases merging dictionaries he resolving of the collisions is always relatively simple. Shouldn’t they be as below maybe? /// Creates a new dictionary using the key/value pairs in the given

Re: [swift-evolution] [swift-evolution-announce] [Review] 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 > On Apr 6, 2017, at 4:10 PM, Douglas Gregor wrote: > > What is your evaluation of the proposal? This proposal is actively

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

I tend to dislike the backslash as well, but can't suggest a good alternative. Does any of this allow for operations within the key path? e.g. Department.employees.@sum.salary? Also, in this example: let firstFriendsNameKeyPath = \Person.friends[0].name let firstFriend = luke[keyPath:

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

> On Apr 6, 2017, at 7:48 PM, Xiaodi Wu wrote: > > On Thu, Apr 6, 2017 at 7:38 PM, Charles Srstka > wrote: >> On Apr 6, 2017, at 7:34 PM, Xiaodi Wu via swift-evolution >>

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

Hi, I am trying to follow the emails. Would that be same as KeyPath ? Or what is that shorthand? Thanks Ricardo > On Apr 6, 2017, at 8:32 PM, Michael J LeHew Jr via swift-evolution > wrote: > > \Vector -> Int seems like a more appropriate spelling

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

> Presumably, proponents of SE-0025. That is, after all, an explicit part of > that design, reviewed and approved by the Swift community and core team. I'd be curious how many people actually are doing this though. My understanding is this practice is not that common overall. Ultimately

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

On Thu, Apr 6, 2017 at 7:43 PM, Riley Testut wrote: > While valid, my understanding is that the use of extensions that *should *have > access to private members is more common than the use of extensions to > explicitly prevent access. > > More importantly though, using

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

On Thu, Apr 6, 2017 at 7:38 PM, Charles Srstka wrote: > On Apr 6, 2017, at 7:34 PM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > > `private` works for extensions exactly how the authors of SE-0025 intended > it to do. Your comments do not

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

>> `private` works for extensions exactly how the authors of SE-0025 intended >> it to do. Your comments do not address what would happen for those people >> who are making use of this functionality currently to isolate methods to the >> extension only. My previous email was in response to

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

While valid, my understanding is that the use of extensions that should have access to private members is more common than the use of extensions to explicitly prevent access. More importantly though, using extensions to prevent access to private members can be accomplished by declaring the

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

> On Apr 6, 2017, at 7:34 PM, Xiaodi Wu via swift-evolution > wrote: > > `private` works for extensions exactly how the authors of SE-0025 intended it > to do. Your comments do not address what would happen for those people who > are making use of this functionality

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

+1 from me. This will solve the great majority of cases where “fileprivate” is currently needed, and will facilitate the common use case of splitting a type’s implementation into multiple extensions. My only wish is that it applied to extensions in the same *module*, rather than the same

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

On Thu, Apr 6, 2017 at 7:28 PM, Riley Testut via swift-evolution < swift-evolution@swift.org> wrote: > I cannot express how strongly I believe this *is *the direction Swift > should go, so a huge, gigantic, > > +1 > from me. > > After thinking it over, I do not have any qualms with fileprivate

Re: [swift-evolution] SE-163: String Revision: Collection Conformance, C Interop, Transcoding

> On Apr 5, 2017, at 10:32 PM, Félix Cloutier wrote: > > During the proposal phase, we asked how this would handle fixed-length > strings with an optional NUL terminator. For instance, in a C `struct Foo { > char name[8]; };`, `name` stops at the first \0, or at the eighth

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

\Vector -> Int seems like a more appropriate spelling there no? The : is usually for is-a/conforms-to relationships, no? And I agree that such a thing could be considered later and would make the world a better place. -Michael > On Apr 6, 2017, at 4:21 PM, Brent Royal-Gordon via

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

I cannot express how strongly I believe this is the direction Swift should go, so a huge, gigantic, +1 from me. After thinking it over, I do not have any qualms with fileprivate itself. I think that the functionality provided by fileprivate is valuable, and I also agree it shouldn’t be the

Re: [swift-evolution] [Pitch] Rename fileprivate to shared

On Thu, Apr 6, 2017 at 3:20 PM, James Froggatt via swift-evolution < swift-evolution@swift.org> wrote: > That's a shame if true, but my interpretation was that the rejection > specifically cited the double-rename of fileprivate to private, and private > to scoped, a major change which renames two

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

> On Apr 6, 2017, at 17:04, Brent Royal-Gordon wrote: > >> On Apr 6, 2017, at 11:17 AM, Jordan Rose via swift-evolution >> > wrote: >> >> Neither, unfortunately. We accepted SE-0025, though I wish we hadn't;

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

If you don't want to resolve the mistake of SE-0025 by proposing a really solution but not a workaround, then just leave the things where they are currently. Proposed "improvement" IMO is more confusing than helping. Sorry, I don't buy <<..most of those proposals are not in scope for

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

> On Apr 6, 2017, at 11:17 AM, Jordan Rose via swift-evolution > wrote: > > Neither, unfortunately. We accepted SE-0025, though I wish we hadn't; we > named the two levels "private" and "fileprivate", though I wish we hadn't; > and now there is lots of existing code

Re: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

> > > • What is your evaluation of the proposal? > In terms of the overarching theme, I think it is delightful. But I am very disappointed that this proposal did not first circulate as a draft in the past few months prior to being sent out for review. I understand that it is an abbreviated

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

> On Apr 6, 2017, at 6:10 PM, Douglas Gregor via swift-evolution > wrote: > > 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 >

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

For the reasons I outlined previously, a very strong -1 as well. I thought it was worthwhile to consider if the Swift 2 design was superior to the Swift 3 design, but I feel very strongly that there should not be a Swift 4 "private" that's different from both Swift 3 and 2. On Thu, Apr 6, 2017 at

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

Strong -1. This is a source breaking change, but Swift 4 stage 2 is already over. Slava > On Apr 6, 2017, at 4:10 PM, Douglas Gregor wrote: > > Hello Swift community, > > The review of SE-0169 "Improve Interaction Between private Declarations and > Extensions" begins now

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

> On Apr 6, 2017, at 2:39 PM, Joe Groff via swift-evolution > wrote: > > for key in [\Vector.x, \.y, \.z, \.w] { > a[key] += b[key] > } Sorry to derail slightly, but I'd love to see a key path type shorthand—perhaps something like: for key: \Vector:

Re: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

> • What is your evaluation of the proposal? I like the feature a lot, but I'm not so sure about the described indentation-stripping behavior. I don't think that putting the closing """ at the same indentation level as the string's contents is very intuitive. It feels a bit like writing this:

[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] SE-163: String Revision: Collection Conformance, C Interop, Transcoding

> On Apr 5, 2017, at 12:39 PM, John McCall via swift-evolution > wrote: > > Hello, Swift community! > > The review of "SE-163: String Revision: Collection Conformance, C Interop, > Transcoding" begins now and runs through next Tuesday, April 11th. The > proposal

Re: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

> On Thu, Apr 6, 2017 at 9:35 PM Joe Groff via swift-evolution > wrote: > > Proposal link: > > https://github.com/apple/swift-evolution/blob/master/proposals/0168-multi-line-string-literals.md > > • What is your evaluation of the proposal? +1 The first

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

> On Apr 6, 2017, at 4:39 PM, Joe Groff wrote: > >> >> On Apr 6, 2017, at 2:35 PM, Matthew Johnson wrote: >> >>> >>> On Apr 6, 2017, at 4:22 PM, Joe Groff wrote: >>> On Apr 6, 2017, at 2:15 PM, Matthew Johnson

Re: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

> On Apr 6, 2017, at 2:35 PM, Joe Groff via swift-evolution > wrote: > > Hello Swift community, > > The review of SE-0168 "Multi-Line String Literals" begins now and runs > through April 12, 2017. The proposal is available here: > >

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

> On Apr 6, 2017, at 2:35 PM, Matthew Johnson wrote: > >> >> On Apr 6, 2017, at 4:22 PM, Joe Groff wrote: >> >>> >>> On Apr 6, 2017, at 2:15 PM, Matthew Johnson wrote: >>> >>> On Apr 6, 2017, at 1:11 PM, Joe Groff

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

> On Apr 6, 2017, at 4:22 PM, Joe Groff wrote: > >> >> On Apr 6, 2017, at 2:15 PM, Matthew Johnson wrote: >> >> >>> On Apr 6, 2017, at 1:11 PM, Joe Groff wrote: >>> >>> On Apr 6, 2017, at 11:06 AM, John McCall

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

> On Apr 6, 2017, at 2:15 PM, Matthew Johnson wrote: > > >> On Apr 6, 2017, at 1:11 PM, Joe Groff wrote: >> >> >>> On Apr 6, 2017, at 11:06 AM, John McCall wrote: >>> On Apr 6, 2017, at 1:41 PM, Matthew Johnson

Re: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

> On Apr 6, 2017, at 3:35 PM, Joe Groff via swift-evolution > wrote: > > Hello Swift community, > > The review of SE-0168 "Multi-Line String Literals" begins now and runs > through April 12, 2017. The proposal is available here: > >

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

> On Apr 6, 2017, at 1:11 PM, Joe Groff wrote: > > >> On Apr 6, 2017, at 11:06 AM, John McCall wrote: >> >>> On Apr 6, 2017, at 1:41 PM, Matthew Johnson wrote: On Apr 6, 2017, at 12:32 PM, John McCall

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

> On Apr 6, 2017, at 2:54 PM, John McCall wrote: > >> >> On Apr 6, 2017, at 3:05 PM, Matthew Johnson > > wrote: >> >> >>> On Apr 6, 2017, at 1:21 PM, John McCall >> >

Re: [swift-evolution] [Pitch] Cross-platform Swift TLS library

Hi Rien, This is great, thanks for referencing your blogs/repo. I'll go through them. (An unfortunate issue I have found with security is that, we need it, we expect it, but we don't want to worry about it :-) The basic structure of what we are considering right now would to a large extent

Re: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

> • What is your evaluation of the proposal? I support the initiative. But I have the question as Greg and Tony: how would one write “”” in side the literal? > • Is the problem being addressed significant enough to warrant a change > to Swift? Yes. > • Does this proposal fit

Re: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

On 06.04.2017 22:35, Joe Groff via swift-evolution wrote: Hello Swift community, The review of SE-0168 "Multi-Line String Literals" begins now and runs through April 12, 2017. The proposal is available here:

Re: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

> On 6 Apr 2017, at 22:34, Haravikk via swift-evolution > wrote: > > >> On 6 Apr 2017, at 20:35, Joe Groff via swift-evolution >> > wrote: >> >> • What is your evaluation of the proposal? > > I'm a

Re: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

> On 6 Apr 2017, at 20:35, Joe Groff via swift-evolution > wrote: > > • What is your evaluation of the proposal? I'm a -1 for several reasons, mostly subjective but still. First thing is that I'm generally not comfortable with encouraging the use of

Re: [swift-evolution] [Pitch] Rename fileprivate to shared

That's a shame if true, but my interpretation was that the rejection specifically cited the double-rename of fileprivate to private, and private to scoped, a major change which renames two access modifier, and reuses a spelling, making a staged migration impossible. Since this suggestion is

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 wrote: > > >> On Apr 6, 2017, at 10:37 AM, Douglas Gregor via swift-evolution >> > wrote: >> >> >>> On Apr 6, 2017, at 10:28 AM, Ricardo Parada

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

> On Apr 6, 2017, at 10:37 AM, Douglas Gregor via swift-evolution > wrote: > > >> 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? >> >>

Re: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

> • What is your evaluation of the proposal? Strong +1. Of all the ideas and proposals for multi-line string literals, this version is my favourite. Supporting copy/pasting and easy editing of multi-line strings is so important that I’m very happy the continuation quotes idea for

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

> On 6 Apr 2017, at 19:41, Jordan Rose via swift-evolution > wrote: > > Hi, -evolution. I’ve said this before, but I think this new proposal is a > terrible idea. It privileges types in a way that is damaging to the language. > > [There isn't really anything new in

Re: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

On Thu, Apr 6, 2017 at 12:35 PM Joe Groff via swift-evolution < swift-evolution@swift.org> wrote: > Hello Swift community, > > The review of SE-0168 "Multi-Line String Literals" begins now and runs > through April 12, 2017. The proposal is available here: > > >

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0168: Multi-Line String Literals

> On Apr 6, 2017, at 12:35 PM, Joe Groff wrote: > > Hello Swift community, > > The review of SE-0168 "Multi-Line String Literals" begins now and runs > through April 12, 2017. The proposal is available here: > >

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

> On Apr 6, 2017, at 3:05 PM, Matthew Johnson wrote: > > >> On Apr 6, 2017, at 1:21 PM, John McCall > > wrote: >> >>> On Apr 6, 2017, at 2:12 PM, Matthew Johnson >>

[swift-evolution] [Review] SE-0168: Multi-Line String Literals

Hello Swift community, The review of SE-0168 "Multi-Line String Literals" begins now and runs through April 12, 2017. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0168-multi-line-string-literals.md Reviews are an important part of the Swift

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

On Apr 6, 2017, at 1:17 PM, Jordan Rose via swift-evolution wrote: > >> On Apr 6, 2017, at 11:10, Vladimir.S wrote: >> >> On 06.04.2017 20:41, Jordan Rose via swift-evolution wrote: >>> Hi, -evolution. I’ve said this before, but *I think this new

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

> On Apr 6, 2017, at 1:21 PM, John McCall wrote: > >> On Apr 6, 2017, at 2:12 PM, Matthew Johnson > > wrote: >>> On Apr 6, 2017, at 1:06 PM, John McCall >> > wrote: >>>

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

On 06.04.2017 21:40, Jordan Rose via swift-evolution wrote: On Apr 6, 2017, at 11:35, Nevin Brackett-Rozinsky via swift-evolution > wrote: On Thu, Apr 6, 2017 at 2:17 PM, Jordan Rose via swift-evolution

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

[Proposal: https://github.com/apple/swift-evolution/blob/master/proposals/0164-remove-final-support-in-protocol-extensions.md ] +1 from me, for all the reasons in the proposal.

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

[Proposal: https://github.com/apple/swift-evolution/blob/master/proposals/0164-remove-final-support-in-protocol-extensions.md ] > On Apr 5, 2017, at 16:15, Howard Lovatt via

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

On 06.04.2017 21:17, Jordan Rose wrote: On Apr 6, 2017, at 11:10, Vladimir.S wrote: On 06.04.2017 20:41, Jordan Rose via swift-evolution wrote: Hi, -evolution. I’ve said this before, but *I think this new proposal is a terrible idea*. It privileges types in a way that is

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

> On Apr 6, 2017, at 11:35, Nevin Brackett-Rozinsky via swift-evolution > wrote: > > On Thu, Apr 6, 2017 at 2:17 PM, Jordan Rose via swift-evolution > > wrote: > > We accepted SE-0025, though I wish we

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

On Thu, Apr 6, 2017 at 2:17 PM, Jordan Rose via swift-evolution < swift-evolution@swift.org> wrote: > > We accepted SE-0025, though I wish we hadn't; we named the two levels > "private" and "fileprivate", though I wish we hadn't; and now there is lots > of existing code relying on that, and it

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

> On Apr 6, 2017, at 2:12 PM, Matthew Johnson wrote: >> On Apr 6, 2017, at 1:06 PM, John McCall > > wrote: >> >>> On Apr 6, 2017, at 1:41 PM, Matthew Johnson >> >

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

> On Apr 6, 2017, at 11:10, Vladimir.S wrote: > > On 06.04.2017 20:41, Jordan Rose via swift-evolution wrote: >> Hi, -evolution. I’ve said this before, but *I think this new proposal is a >> terrible idea*. It privileges types in a way that is damaging to the >> language. >>

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

Yes. I'd prefer to keep unapplied method references the same and do properties the same way IMHO. On Thu, Apr 6, 2017 at 12:05 PM, Douglas Gregor wrote: > > On Apr 6, 2017, at 11:01 AM, Brad Hilton wrote: > > -1. Not a huge fan of the back slash.

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

> On Apr 6, 2017, at 1:06 PM, John McCall wrote: > >> On Apr 6, 2017, at 1:41 PM, Matthew Johnson > > wrote: >>> On Apr 6, 2017, at 12:32 PM, John McCall >> > wrote: >>>

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

> On Apr 6, 2017, at 11:06 AM, John McCall wrote: > >> On Apr 6, 2017, at 1:41 PM, Matthew Johnson wrote: >>> On Apr 6, 2017, at 12:32 PM, John McCall wrote: >>> On Apr 5, 2017, at 9:46 PM, Matthew Johnson via

[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

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

On 06.04.2017 20:41, Jordan Rose via swift-evolution wrote: Hi, -evolution. I’ve said this before, but *I think this new proposal is a terrible idea*. It privileges types in a way that is damaging to the language. [There isn't really anything new in my discussion below; everyone on-thread is

[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] [Returned for revision] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

> On Apr 6, 2017, at 1:41 PM, Matthew Johnson wrote: >> On Apr 6, 2017, at 12:32 PM, John McCall > > wrote: >> >>> On Apr 5, 2017, at 9:46 PM, Matthew Johnson via swift-evolution >>>

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

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

-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 Person.name.get / Person.name.set for getter/setter references. > Hello Swift community, > >

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

If single quotes are out, then I would suggest requiring a parenthesis. I guess I just don’t like that it’s unbounded and I’m sure that’s some kind of personal preference thing, but what isn’t around here? :P For example: \(Person.name) instead of: \Person.name I think an argument could be

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

Dear Colleague Travellers In Turbulent And Interesting Digital Times :) Sorry, that I have not read all other opinions on this thread thoroughly, there's so much of it which confuses me. The sheer volume of this traffic gives me the impression that scope management is Swift is fundamentally

Re: [swift-evolution] Make class and struct members private by default / Type-Based access

Hi David jikes! You’re right, total blunder. I should do my homework better :o) I have been using Java before, be it with the assumption that it had private scope for class members, because of the line of PLs I was using before I started using Java I went on programming assuming that it had,

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

> On Apr 6, 2017, at 12:32 PM, John McCall wrote: > >> On Apr 5, 2017, at 9:46 PM, Matthew Johnson via swift-evolution >> > wrote: >>> On Apr 5, 2017, at 7:32 PM, David Smith via swift-evolution >>>

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

Hi, -evolution. I’ve said this before, but I think this new proposal is a terrible idea. It privileges types in a way that is damaging to the language. [There isn't really anything new in my discussion below; everyone on-thread is smart enough to have brought up these points already. But I

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] [Returned for revision] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

> On Apr 5, 2017, at 9:46 PM, Matthew Johnson via swift-evolution > wrote: >> On Apr 5, 2017, at 7:32 PM, David Smith via swift-evolution >> > wrote: >> >> The rationale for using the same syntax is that a

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

Yes but that is a bit different. Spaces can be used for clarity or breaking up a chain into multiple lines maybe. But, the space is not really part of the key path. I would expect the key path to be typed in without spaces when using the special syntax. > On Apr 6, 2017, at 12:45 PM, Ben

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

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 the root object and keys forming the path. That way I can go to an object model,

[swift-evolution] Warning on name collisions with functions in protocol extensions

Has there been any conversation around generating a warning if a type implements a function that is also implemented in an extension of a conforming protocol? This is a frequent source of confusion for new swift developers, and I think the reaction to this behavior is more severe than it needs to

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

>> On Apr 5, 2017, at 6:54 PM, Nevin Brackett-Rozinsky via swift-evolution >> > wrote: >> >> On Wed, Apr 5, 2017 at 12:02 AM, Chris Lattner via swift-evolution >> > wrote:

Re: [swift-evolution] [Pitch] Cross-platform Swift TLS library

Having just finished a client/server framework that builds on openSSL I sympathise with this proposal. However, I wrote a few blogposts about my experiences with openSSL. And those leads me to believe that there is not much interest in secure networking. The number of hits on those posts are

Re: [swift-evolution] SE-165: Dictionary & Set Enhancements

> On Apr 5, 2017, at 9:43 PM, Brent Royal-Gordon via swift-evolution > wrote: > >> On Apr 5, 2017, at 5:45 PM, Ben Cohen via swift-evolution >> > wrote: >> >> • What is your evaluation of the

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

> On 6 Apr 2017, at 16:29, Ricardo Parada via swift-evolution > wrote: > > Another thought on the use of single quotes (an possibly the proposed escape > character). Do you think the closing single quote could be made optional > since key paths cannot have spaces?

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

On Thu, Apr 6, 2017 at 9:31 AM Sean Heber via swift-evolution < swift-evolution@swift.org> wrote: > > > On Apr 6, 2017, at 11:19 AM, Douglas Gregor wrote: > > > >> > >> On Apr 6, 2017, at 8:13 AM, Ricardo Parada via swift-evolution < > swift-evolution@swift.org> wrote: > >> >

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

> On Apr 6, 2017, at 11:19 AM, Douglas Gregor wrote: > >> >> 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

  1   2   >