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

Wow, thanks a lot for this detailed rewrite! Looks like something worth evaluating now :-) > Is the “magic" leading whitespace removal a good idea to support indentation. It's worth mentioning that the updated proposal contains ways to avoid the automatic indentation processing. Gwendal > Le

Re: [swift-evolution] Proposal: Split extensions into implementing methods and adding static functions Was: [swift-evolution-announce] [Review] SE-0164: Remove final support in protocol extensions

I myself pitched that requirement quite a few times on the list. Thank you, finally I understood why it’s not possible. Now I fully agree that the requirement of an override should not exist for the base type conforming to the protocol. For those who might misunderstand the concept of

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

> • What is your evaluation of the proposal? Positive. I could not stress enough how the attitude behind such a proposal is *positive*. > • Is the problem being addressed significant enough to warrant a change > to Swift? Yes. private / fileprivate had a tremendous design issue:

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

> Le 8 avr. 2017 à 00:45, Jordan Rose a écrit : > > >> On Apr 7, 2017, at 04:18, Gwendal Roué via swift-evolution >> wrote: >> >> - the private/fileprivate qualifier used not to be a intrinsic property of >> an object (because one had to

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

That’s also the example that kept me thinking for a while. Overall the proposal is a great compromise to some issues I had with the first version. However I have a few more questions: Why can’t we make it consistent and let the compiler add a new line after the starting delimiter. 
let string

Re: [swift-evolution] Enhancing access levels without breaking changes

> On 11 Apr 2017, at 13:29, Jonathan Hull wrote: > >> >> On Apr 11, 2017, at 3:53 AM, David Hart via swift-evolution >> > wrote: >> >> On 11 Apr 2017, at 09:40, John McCall >

Re: [swift-evolution] Enhancing access levels without breaking changes

Sent from my iPad > On Apr 11, 2017, at 8:53 AM, David Hart via swift-evolution > wrote: > > >>> On 11 Apr 2017, at 13:29, Jonathan Hull wrote: >>> >>> >>> On Apr 11, 2017, at 3:53 AM, David Hart via swift-evolution >>>

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

On 11.04.2017 16:35, John Holdsworth via swift-evolution wrote: I feel discussion on this proposal is nearing general agreement that while the gist of it it seems reasonable to many there is also not enough detail in it as submitted. Brent has person-fully stepped in and rewritten the draft to

Re: [swift-evolution] switch must be exhaustive, consider adding a default clause

> On Apr 8, 2017, at 11:29 AM, Drew Crawford via swift-evolution > wrote: > > > > Is there a good reason we do not compile this: > > import UIKit > > func foo(operation: UINavigationControllerOperation) { > switch(operation) { > case .push: /* snip */

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

Can you elaborate a small example please, so I can better understand what you asked for? --  Adrian Zubarev Sent with Airmail Am 11. April 2017 um 18:51:45, Ricardo Parada (rpar...@mac.com) schrieb: Hi Adrian, I think having the closing """ on a line by itself activates the indentation

Re: [swift-evolution] switch must be exhaustive, consider adding a default clause

On April 11, 2017 at 11:38:05 AM, Joe Groff (jgr...@apple.com) wrote: By design, Swift avoids making semantic rules based on that kind of analysis, since it would be brittle and difficult to describe when the compiler can and can't see that a condition holds nonlocally like this. Swift

Re: [swift-evolution] Enhancing access levels without breaking changes

> On 11 Apr 2017, at 16:27, Matthew Johnson wrote: > > > > Sent from my iPad > >> On Apr 11, 2017, at 8:53 AM, David Hart via swift-evolution >> wrote: >> >> On 11 Apr 2017, at 13:29, Jonathan Hull wrote:

[swift-evolution] [Accepted] SE-0162 Package Manager Custom Target Layouts

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0162-package-manager-custom-target-layouts.md The review of SE-0162 "Package Manager Custom Target Layouts" ran from April 4th until April 10th. The proposal is accepted. The feedback we received prior to and during

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

> On Apr 9, 2017, at 8:44 PM, Brent Royal-Gordon via swift-evolution > wrote: > > To back up that last point, I ran through the thread and tried to quickly > figure out what everyone was thinking. These people seem to be opposed to the > proposal: > > 2.

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

> On Apr 6, 2017, at 4:25 PM, Slava Pestov via swift-evolution > wrote: > > Strong -1. This is a source breaking change, but Swift 4 stage 2 is already > over. I agree with you here. I don't think the proposal will be accepted as is, because of the breaking

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

Hi Adrian, I think having the closing """ on a line by itself activates the indentation stripping feature. So if it was to change as you suggest then how would you turn off indentation stripping? > On Apr 11, 2017, at 11:08 AM, Adrian Zubarev via swift-evolution >

Re: [swift-evolution] Reduce with inout

Ping. What’s the latest on this proposal? Seems like a clear win to me. It seems the thread converged on a name if we want 2 versions of reduce. Should we simply replace the existing version so there’s only one? Really wish this can get in Swift 4. > On Jan 25, 2017, at 1:06 AM, Chris Eidhof

Re: [swift-evolution] Enhancing access levels without breaking changes

> On Apr 11, 2017, at 12:00 PM, David Hart via swift-evolution > wrote: > > > > On 11 Apr 2017, at 16:27, Matthew Johnson > wrote: > >> >> >> Sent from my iPad >> >> On Apr 11, 2017, at 8:53 AM, David

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

On Apr 9, 2017, at 7:04 PM, Jose Cheyo Jimenez via swift-evolution wrote: > > On Apr 8, 2017, at 5:19 AM, Neil via swift-evolution > > wrote: > >> I agreed with Charlie, but I think there’s another option.

Re: [swift-evolution] [pitch] Adding in-place removeAll to the std lib

> On Apr 10, 2017, at 13:30, Kevin Nattinger via swift-evolution > wrote: > > array.remove(where: { $0 > 3 }) > array.remove { $0 > 3 } `where` is the best label for this. `filter` doesn’t have an overload for Comparable, this doesn’t need one either. Cheers,

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

> 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 is available here: >

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

> Hello Swift community, > > The second review of SE-0161 "Smart KeyPaths: Better Key-Value Coding for > Swift" begins now and runs through April 9, 2017. The revised proposal is > available here: > >

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

> On Apr 11, 2017, at 7:33 AM, Vladimir.S via swift-evolution > wrote: > > 2. Seems like a mistake: > "Multi-line string with indentation stripping prevented by whitespace before > leading newline" > > """↵ > Hello↵ > world!""" > > Creates a string with: >

Re: [swift-evolution] Enhancing access levels without breaking changes

We’re not talking about the same proposal. I’m talking about SE-0169 > On 11 Apr 2017, at 19:49, Daniel Duan wrote: > > This never went into a review. The pull request is still open > https://github.com/apple/swift-evolution/pull/587 >

Re: [swift-evolution] Enhancing access levels without breaking changes

SE-0169 is under active review, and is about expanding the meaning of scope to include extensions in the same file. The last day of the review period is today. What is this about yet another change? On Tue, Apr 11, 2017 at 14:31 David Hart via swift-evolution < swift-evolution@swift.org> wrote:

Re: [swift-evolution] Enhancing access levels without breaking changes

> On Apr 11, 2017, at 3:37 PM, Xiaodi Wu via swift-evolution > wrote: > SE-0169 is under active review, and is about expanding the meaning of scope > to include extensions in the same file. The last day of the review period is > today. > > What is this about yet

Re: [swift-evolution] Enhancing access levels without breaking changes

Great, thanks for the clarification. On Tue, Apr 11, 2017 at 14:50 John McCall wrote: > On Apr 11, 2017, at 3:37 PM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > SE-0169 is under active review, and is about expanding the meaning of > scope to include

Re: [swift-evolution] Enhancing access levels without breaking changes

I don't want to make any change until Chris has been able to chime in. If he agrees with us, what should be done? • Immediate change in the proposal? • Would it have to go through a new review? • Or can the Core Team make the change if it is accepted? > On 11 Apr 2017, at 19:01, John McCall

Re: [swift-evolution] Enhancing access levels without breaking changes

This never went into a review. The pull request is still open https://github.com/apple/swift-evolution/pull/587 > On Apr 11, 2017, at 10:45 AM, David Hart via swift-evolution > wrote: > > I don't want to make any change until Chris has been able to chime in. If he >

Re: [swift-evolution] Enhancing access levels without breaking changes

> On Apr 11, 2017, at 10:45 AM, David Hart via swift-evolution > wrote: > > I don't want to make any change until Chris has been able to chime in. If he > agrees with us, what should be done? > > • Immediate change in the proposal? > • Would it have to go through

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

>> — It adds no power to the language >> The proposal solves no real problem, but rather encourages a certain style >> of programming, which is quite popular among authors of styleguides, but has >> no clear net gain. > > While your other points are defendable, I have to disagree here. It does

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

> On Apr 11, 2017, at 8:08 AM, Adrian Zubarev via swift-evolution > wrote: > > That’s also the example that kept me thinking for a while. > > Overall the proposal is a great compromise to some issues I had with the > first version. However I have a few more

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

If Xcode or code editors displayed a vertical line at the indentation boundary then it would be like having the continuation character without actually being there. The best of both worlds. That would be really nice. > On Apr 11, 2017, at 8:48 PM, Ricardo Parada via swift-evolution >

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

> On Apr 11, 2017, at 5:50 PM, Xiaodi Wu via swift-evolution > wrote: > > On Tue, Apr 11, 2017 at 7:32 PM, Brent Royal-Gordon via swift-evolution > > wrote: > >> On Apr 11, 2017, at 8:08 AM, Adrian

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

On 11.04.2017 19:47, Jose Cheyo Jimenez via swift-evolution wrote: On Apr 6, 2017, at 4:25 PM, Slava Pestov via swift-evolution > wrote: Strong -1. This is a source breaking change, but Swift 4 stage 2 is already over. I agree

Re: [swift-evolution] Proposal: Split extensions into implementing methods and adding static functions Was: [swift-evolution-announce] [Review] SE-0164: Remove final support in protocol extensions

Thanks for the explanation Adrian, I also had to Google this :) Personally I'd love some kind of solution that would prevent this confusion of why this method does different things when called on the same object in two different ways, but I don't have any ideas how this could be solved... It's

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

> On Apr 11, 2017, at 8:32 PM, Brent Royal-Gordon via swift-evolution > wrote: > ... > But I'd love to see a faint reddish background behind tripled string literal > content or a vertical line at the indentation boundary. That would be very nice. :-)

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

Sure. Let me quote the proposal: "We propose that, when the opening delimiter ends its line and the closing delimiter starts its line, tripled string literals should automatically remove whatever indentation is present before the closing delimiter from each line above it, as well as removing

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

> On Apr 11, 2017, at 7:33 AM, Vladimir.S via swift-evolution > wrote: > > 1. "Tripled string literals support backslash escapes and interpolation as > normal, except that you can also place a backslash immediately before a > newline. This indicates that the newline

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

On Tue, Apr 11, 2017 at 7:50 PM, Xiaodi Wu wrote: > On Tue, Apr 11, 2017 at 7:32 PM, Brent Royal-Gordon via swift-evolution < > swift-evolution@swift.org> wrote: > >> >> On Apr 11, 2017, at 8:08 AM, Adrian Zubarev via swift-evolution < >> swift-evolution@swift.org> wrote: >>

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

> On Apr 11, 2017, at 8:18 PM, Jakub Suder via swift-evolution > wrote: > > I'm honestly having trouble believing that this is being seriously > proposed... I always saw type inference as one of the most important > advantages of Swift over some older languages,

Re: [swift-evolution] switch must be exhaustive, consider adding a default clause

What Joe is referring to is the kind of refinement-style rules that would be necessary to teach the type checker about how to that kind of analysis. Right now, all our switch analysis, and even this example, are just DI and control-flow checks. > On Apr 11, 2017, at 2:24 PM, Drew Crawford via

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

I'm honestly having trouble believing that this is being seriously proposed... I always saw type inference as one of the most important advantages of Swift over some older languages, the Swift ebook mentions many times how smart Swift is that it can infer types for you so that you don't have to

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

On Tue, Apr 11, 2017 at 7:32 PM, Brent Royal-Gordon via swift-evolution < swift-evolution@swift.org> wrote: > > On Apr 11, 2017, at 8:08 AM, Adrian Zubarev via swift-evolution < > swift-evolution@swift.org> wrote: > > That’s also the example that kept me thinking for a while. >

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

> On Apr 11, 2017, at 4:52 PM, Ricardo Parada via swift-evolution > wrote: > > I think the enabling of the indentation stripping could be relaxed a little > bit and not require the opening delimiter to end its line. So for example, > it would be possible to do

[swift-evolution] ABI dashboard now up

Hi everyone, We now have a dashboard up on Swift.org to track remaining tasks for ABI stability: https://swift.org/abi-stability/ The contents of the dashboard (which we may refine over time*) are largely drawn from JIRA and the ABI manifesto:

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

> On 12 Apr 2017, at 02:50, Xiaodi Wu via swift-evolution > wrote: > >> On Tue, Apr 11, 2017 at 7:32 PM, Brent Royal-Gordon via swift-evolution >> wrote: >> >>> On Apr 11, 2017, at 8:08 AM, Adrian Zubarev via swift-evolution >>>

Re: [swift-evolution] Enhancing access levels without breaking changes

On Apr 11, 2017, at 10:30 PM, David Hart wrote: >> To me, the reason for limiting it to a file is about predictability, the >> ability to locally reason about a type, and the need to define some boundary >> (for symbol visibility reasons). Saying that extensions to a type

Re: [swift-evolution] Enhancing access levels without breaking changes

On Apr 11, 2017, at 3:53 AM, David Hart via swift-evolution wrote: >>> I understand what you are saying and I wouldn't be against relaxing that >>> requirement (not talking for Chris here). >>> >>> The model would change from "Types share scopes with their extensions

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

> On Apr 7, 2017, at 4:07 AM, Vladimir.S via swift-evolution > wrote: > > On 07.04.2017 10:21, Daniel Duan via swift-evolution wrote: >> Hi all, >> >> In a discussion about inferring parameter types from default value, >> Slava brought up some performance problems

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

> On Apr 10, 2017, at 12:28 PM, John McCall via swift-evolution > wrote: > >> Speaking just for myself, I don't think we'd accept such a change purely for >> aesthetics; >> >> If I recall correctly, Chris in post-review discussions communicated that a >> new

Re: [swift-evolution] Enhancing access levels without breaking changes

> On Apr 11, 2017, at 10:45 AM, David Hart via swift-evolution > wrote: > > I don't want to make any change until Chris has been able to chime in. If he > agrees with us, what should be done? The rationale here is to propose the minimal thing that improves the

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

We currently pay a dear cost in compilation time for all the features Swift brings and this in itself harm productivity quite a bit, the gulf between Swift and Objective-C projects compile time wise is massive and right nowt seems like we are ignoring it sometimes. Type inference can be a non

Re: [swift-evolution] Enhancing access levels without breaking changes

> On Apr 11, 2017, at 1:34 AM, David Hart via swift-evolution > wrote: > > Sent from my iPhone > On 11 Apr 2017, at 01:37, Ricardo Parada via swift-evolution > > wrote: > >> I have not voted in favor or

Re: [swift-evolution] SE-0169

Sent from my iPhone > On 11 Apr 2017, at 02:41, Michael Mayer via swift-evolution > wrote: > > All - > > I am not in favor of this change. While I agree that the implementation of > fileprivate and open as well as the changes to private had some unintended >

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

-1 (strong) I think I've read all messages and haven't much to add — so just to sum up my concerns in order: — It makes access control more complicated For me, it's not about the complexity itself (it's not terrible huge, after all), but I believe in the beauty of simplicity, which is already

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

> On Apr 6, 2017, at 11:10 AM, Douglas Gregor wrote: > > Proposal link: > > https://github.com/apple/swift-evolution/blob/master/proposals/0166-swift-archival-serialization.md > >

Re: [swift-evolution] Enhancing access levels without breaking changes

> On Apr 11, 2017, at 3:53 AM, David Hart via swift-evolution > wrote: > > On 11 Apr 2017, at 09:40, John McCall > wrote: > >>> On Apr 11, 2017, at 1:34 AM, David Hart via swift-evolution >>>

Re: [swift-evolution] Proposal: Split extensions into implementing methods and adding static functions Was: [swift-evolution-announce] [Review] SE-0164: Remove final support in protocol extensions

On 11.04.2017 1:51, Xiaodi Wu via swift-evolution wrote: > On Mon, Apr 10, 2017 at 5:35 PM, Howard Lovatt via swift-evolution > > wrote: > > In response to Jordan Rose's comment I suggest the following change: > > Proposal:

Re: [swift-evolution] SE-0169

> On 11 Apr 2017, at 09:24, Goffredo Marocchi via swift-evolution > wrote: > > > > Sent from my iPhone > >> On 11 Apr 2017, at 02:41, Michael Mayer via swift-evolution >> wrote: >> >> All - >> >> I am not in favor of this change.

Re: [swift-evolution] Enhancing access levels without breaking changes

> On 11 Apr 2017, at 09:40, John McCall wrote: > >> On Apr 11, 2017, at 1:34 AM, David Hart via swift-evolution >> wrote: >> >> Sent from my iPhone >> On 11 Apr 2017, at 01:37, Ricardo Parada via swift-evolution >>

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

> On 11 Apr 2017, at 08:48, Tino Heth via swift-evolution > wrote: > > -1 (strong) > > I think I've read all messages and haven't much to add — so just to sum up my > concerns in order: > — It makes access control more complicated > For me, it's not about the

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

I feel discussion on this proposal is nearing general agreement that while the gist of it it seems reasonable to many there is also not enough detail in it as submitted. Brent has person-fully stepped in and rewritten the draft to translate it into a detailed specification which I’ve updated