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

I saw those too and forgot to point those out. I assumed they were typos. > On Apr 6, 2017, at 9:03 AM, Ed Wellbrook wrote: > > Apologies if I’ve simply just missed something, but are the trailing right > parentheses in the proposed solution intentional? Reading

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

As the title says, I think renaming `fileprivate` to `shared` is the simplest way to solve the issues we have with spelling. My first line of reasoning is that it only affects one modifier, leaving private as it is. This minimises the amount of code affected, making it much more

Re: [swift-evolution] [Pitch] Add an all algorithm to Sequence

In additional, containsAll(value: "123") is prefer and more natural as we speak. On Thursday, April 6, 2017, Muse M wrote: > I accept "contains" for at least match one result, similar to OR. > "containsOnly" is similar to AND for one element or more elements must >

Re: [swift-evolution] Pitch: Compound name `foo(:)` for nullary functions

> On Apr 6, 2017, at 7:02 AM, Xiaodi Wu via swift-evolution > wrote: > > Given that \foo(bar:baz:) will work, and that \foo() will be unambiguously > distinguished from foo(), I think that would be the only logical result. Agree. It seem like this would fit nicely

Re: [swift-evolution] [Pitch] Add an all algorithm to Sequence

I accept "contains" for at least match one result, similar to OR. "containsOnly" is similar to AND for one element or more elements must contain same values and types. On Thursday, April 6, 2017, Xiaodi Wu via swift-evolution < swift-evolution@swift.org> wrote: > In JavaScipt they are known as

Re: [swift-evolution] [Pitch] Add an all algorithm to Sequence

If we were looking for conciseness then my picks would be: every() - every elements meets condition any() - anyone element meets condition none() - none of the elements meets condition Examples: nums.every { isEven } nums.any { isEven } nums.none { isEven } nums.every(matches: { isEven })

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

Re: > On 6 Apr 2017, at 04:13, Xiaodi Wu wrote: > >> On Wed, Apr 5, 2017 at 9:21 PM, Ricardo Parada wrote: >> >>> On Apr 5, 2017, at 9:41 PM, Brent Royal-Gordon wrote: >>> >>> It's worth

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

Apologies if I’ve simply just missed something, but are the trailing right parentheses in the proposed solution intentional? Reading through the code, having loosely followed this discussion, I’m really confused. Examples: ``` // create a key path and use it let firstFriendsNameKeyPath =

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

> On 6 Apr 2017, at 15:03, Ed Wellbrook via swift-evolution > wrote: > > Apologies if I’ve simply just missed something, but are the trailing right > parentheses in the proposed solution intentional? Reading through the code, > having loosely followed this

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

Ah! I will fix those. That is a find replace fail for #keyPath( -> \. Vs #keyPath\(.*\) -> \\\1 > On Apr 6, 2017, at 6:16 AM, Ricardo Parada via swift-evolution > wrote: > > I saw those too and forgot to point those out. I assumed they were typos. > > > >> On

Re: [swift-evolution] Pitch: Compound name `foo(:)` for nullary functions

Agree. > On Apr 6, 2017, at 8:02 AM, Xiaodi Wu via swift-evolution > wrote: > > Given that \foo(bar:baz:) will work, and that \foo() will be unambiguously > distinguished from foo(), I think that would be the only logical result. > > > On Thu, Apr 6, 2017 at

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

This analysis feels pretty right to me and I’m not convinced we even *need* anything more restrictive than a file-wide private. If you want to lock some implementation detail up tight to keep something safe, then it might be a sign that you should refactor that type and pull that critical bit

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] [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

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

On 06.04.2017 18:10, Ricardo Parada via swift-evolution wrote: I did not mention single quotes because I was assuming those were reserved for string literals. But if they are available for something like this, it would make it obvious where the key path begins and where it ends. I went through

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

The escape character is already being used in String interpolation, i.e. \(foo). Also, escaping special characters in string literals, i.e. \t is tab, \n is a newline character, etc. The single quote does not appear to be in use. I believe it's not being used for string literals nor character

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

>> That's an interesting point. While `\` alone seems acceptable, I think it's >> unfortunate that we'll have `(\...)` and `\(...)` both in the language. >> Can we maybe consider instead: >> >> let firstFriendsNameKeyPath = \Person.friends[0].name\ > > 'Single quotes' (i.e. U+0027

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

I did not mention single quotes because I was assuming those were reserved for string literals. But if they are available for something like this, it would make it obvious where the key path begins and where it ends. I went through my hypothetical code samples, and I don't mind the \ escape

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

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? Or would that be confusing for beginners? For example, these two would be equivalent: let

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

+1. These are needed and well-considered enhancements. > On Apr 5, 2017, at 5:45 PM, Ben Cohen via swift-evolution > wrote: > > Hello, Swift community! > > The review of "SE-165: Dictionary & Set Enhancements" begins now and runs > through next Tuesday, April 11th.

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

+1. This is well thought out and an important evolution of string. > On Apr 5, 2017, at 11:39 AM, John McCall via swift-evolution > wrote: > > Hello, Swift community! > > The review of "SE-163: String Revision: Collection Conformance, C Interop, > Transcoding"

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

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. > On Apr 6, 2017, at 11:08 AM, Sean Heber via swift-evolution > wrote: > >>> That's an interesting point. While `\` alone

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

+1 to this revised proposal. I think the backslash is good. Even if it looks a little funny on first blush, I think it’s the best choice. I don’t like other’s suggestion of ‘keypath’, which I think is confusingly string-like: single quotes should be saved for possible string expansions. > On

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

[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

[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

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 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 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] [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,

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] [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 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] 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] 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] [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

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

> 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] [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] [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] [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] 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] [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] 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

> • 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] [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] 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] [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] [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: >>>

[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] [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] [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] [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 >>

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] 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-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] [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

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] [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] [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: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 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] 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] [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: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] [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] [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] [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] Type-based ‘private’ access within a file

Best summary I’ve read on this thread for days! :) > 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 >

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

> On 6 Apr 2017, at 06:56, David Hart via swift-evolution > wrote: > > > > On 6 Apr 2017, at 04:21, Ricardo Parada via swift-evolution > > wrote: > >> >>> On Apr 5, 2017, at 9:41 PM, Brent Royal-Gordon

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

Hello, > 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 > >

Re: [swift-evolution] [Pitch] Add an all algorithm to Sequence

On Thu, Apr 6, 2017 at 12:44 AM, Jonathan Hull via swift-evolution < swift-evolution@swift.org> wrote: > On that note: ‘containsOnly' is still my favorite by a wide margin. I > know it is longer than ‘all’, but it’s behavior is much clearer (especially > for those of us who have never used or

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

On Thu, Apr 6, 2017 at 12:05 AM, Douglas Gregor via swift-evolution < swift-evolution@swift.org> wrote: > >- What is your evaluation of the proposal? > > +1 This small inconsistency can lead to pretty hard debugging session. I think the protocols will still need some extra work because, as

[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] [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] 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] 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

>> `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 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

> 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] [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] [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] [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

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] [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] [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] [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:

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] 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-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

  1   2   >