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

> On 10 Apr 2017, at 05:08, Jose Cheyo Jimenez via swift-evolution > wrote: > > >> On Apr 9, 2017, at 7:14 PM, Jonathan Hull via swift-evolution >> wrote: >> >> This struck me as a bit odd at first, but the more I think about it, the

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

> On 10 Apr 2017, at 04:46, Xiaodi Wu via swift-evolution > wrote: > > Well, if we're going to bikeshed: > > I think removeAll(3) reads fine, while removeAll(of: 3) does not. I do not > think that reads right at all--what is "all of three"? Do we mean to contrast

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

> On Apr 9, 2017, at 8:46 PM, Félix Cloutier wrote: > > For XML, I know that you have this XMLString idea, but I think that it would > be very complex to implement in practice. XML has several different contexts > in which escaping has to be different. For instance, you

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

On Thu, Apr 6, 2017 at 4:10 PM Douglas Gregor via swift-evolution < swift-evolution@swift.org> 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 > available

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

To be clear, I don't think that it's a particularly powerful footgun. It's just perpetuating the unfortunate status quo on injection vulnerabilities. C# was able to eliminate the whole class of SQL injections by introducing a convenient and powerful syntax for queries that is not string-based.

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

> On Apr 9, 2017, at 7:14 PM, Jonathan Hull via swift-evolution > wrote: > > This struck me as a bit odd at first, but the more I think about it, the more > I really like the ability to nest extensions/scopes. The one issue I see is > sticking that public

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

Type inference is one of my favorite features of Seift. I don't think anything would make me change my mind. I read the proposal and couldn't quite figure out why such a request. I still have to read the links that explain why though. Regards > On Apr 9, 2017, at 10:05 PM, Daniel Duan via

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

I agree the sentiment is entirely positive, but speaking for myself only, I would not like to see this proposal accepted in its current form. It needs to be returned for more design and discussion. The idea of multiline strings is not at issue here, except for a small minority of community

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

Well, if we're going to bikeshed: I think removeAll(3) reads fine, while removeAll(of: 3) does not. I do not think that reads right at all--what is "all of three"? Do we mean to contrast it to "some of three"--like, maybe, two of three? By comparison, index(of: 3) works because the element equal

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

> On Apr 9, 2017, at 9:29 AM, John Holdsworth via swift-evolution > wrote: > > Perhaps we can find common ground on 1) and 2) and even 3) with a view to > resubmitting if there is time. Seems mostly like we just need to discuss the > delimiter further and decide

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

> On Apr 8, 2017, at 12:03, Ben Cohen via swift-evolution > wrote: > > > > Hi swift-evolution, > > Another short proposal related to the Collection algorithms theme, this time > for removing elements in-place from a collection. > > Online copy here: >

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

> On Apr 8, 2017, at 5:41 PM, Brent Royal-Gordon wrote: > >> On Apr 8, 2017, at 12:44 PM, Xiaodi Wu via swift-evolution >> > wrote: >> >> +1. Perfect. Let's not bikeshed this and get it done! > > > Sorry,

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

Hi Tino, > On 8 Apr 2017, at 22:03, Tino Heth via swift-evolution > wrote: > > I wish this would only be a joke, but writing the example, I actually started > liking the concept (but I have a terrible headache right now which might > affect my mind) — so either

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

This struck me as a bit odd at first, but the more I think about it, the more I really like the ability to nest extensions/scopes. The one issue I see is sticking that public extension inside a private one. I think you would have to mark ‘secret: Int’ as private instead of the extension

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

I’m still not sure whether *I* want this. But here’s a proposal anyways: https://gist.github.com/dduan/5017a0b0f0880d014f4ce14c4ca7fb55 > On Apr 7, 2017, at 12:21 AM, Daniel Duan via swift-evolution >

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

On Apr 9, 2017, at 12:29 PM, John Holdsworth via swift-evolution > wrote: > Hi, John here, the submitter of the proposal. > > First up, I must apologise for putting Brent on the spot when I resubmitted > this altered proposal from

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

> On Apr 8, 2017, at 5:19 AM, Neil via swift-evolution > wrote: > > I agreed with Charlie, but I think there’s another option. > > The access control problems that both SE-0159 and SE-0169 are attempting to > address can be resolved not by changing the definition

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

> On Apr 9, 2017, at 9:29 AM, John Holdsworth via swift-evolution > wrote: > > Looking at 3) which is underspecified in the proposal perhaps, I’d consider > it a “feature" but I can see it would be too magical for some. To specify it > more you could say: if there

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

I am 110% AGAINST this change. Having complex expressions as a stored property initializer is bad practice anyway, and having the type prefixed in that case provides at best marginal improvement in clarity and doesn’t fix the underlying problem. Type inference on simple expressions allows

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

Brent, can you share your playground, or perhaps put it up in a repo? I think it would be very useful to help the rest of us evaluate the proposal. Jon > On Apr 4, 2017, at 4:57 AM, Brent Royal-Gordon via swift-evolution > wrote: > >> On Apr 3, 2017, at

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

+1 with the clarifications provided in the thread. On Sun, Apr 9, 2017 at 4:44 AM, Howard Lovatt via swift-evolution < swift-evolution@swift.org> wrote: > Review of SE-0168 "Multi-Line String Literals" > > • What is your evaluation of the proposal? > > Yes good idea. Though I am not clear as to

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

I generally dislike any language change desired because it makes the compiler implementation easier. We saw a few such changes for Swift 3 and all of them were net negatives for the actual users of the language (to a minor extent for most, to be fair). I would hope that, as the

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

Review of SE-0168 "Multi-Line String Literals" • What is your evaluation of the proposal? Yes good idea. Though I am not clear as to whether the final return before the closing """ is included in the literal or not. If not, would a blank line before """ enclose a return at the end. If

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

Review of SE-0169 "Improve Interaction Between private Declarations and Extensions" What is your evaluation of the proposal? Yes. Would prefer Swift 2 model but given that that is rejected this is a good compromise. Is the problem being addressed significant enough to warrant a change to

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

Daniel Duan Sent from my iPhone > On Apr 9, 2017, at 9:29 AM, John Holdsworth via swift-evolution > wrote: > > Hi, John here, the submitter of the proposal. > > First up, I must apologise for putting Brent on the spot when I resubmitted > this altered proposal

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

-1: Although prefix "\" is imho the nicest variation that has been officially suggested for this feature (I still like infix ":" better; maybe I've been using classic MacOS to long), there is no general agreement, and many people that voted "+1" did so despite preferring a different syntax,

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

Hi, John here, the submitter of the proposal. First up, I must apologise for putting Brent on the spot when I resubmitted this altered proposal from last year. That was my mistake. Second up, apologies if the proposal is rather vague on details. In some sense this was intentional as I didn’t

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

+1 on removing the inference. I actually always declare the type for stored properties as well for better readability... > On Apr 9, 2017, at 5:28 PM, Lucas Neiva via swift-evolution > wrote: > > (Forgot CC. How's that Discord coming along? ) > > On 7 Apr 2017, at

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

(Forgot CC. How's that Discord coming along? ) > On 7 Apr 2017, at 13:07, Lucas Neiva wrote: > > +1 > > I think declaring property types is beneficial to readability. > > It seems to me like properties are on the same level as functions, where > types are also not inferred. I

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

If inference only works in simple cases, I think it would seem like it works unpredictability to anyone unfamiliar with the implementation details. I image the question of "why do I have to declare a type here, but not in this case?" coming up. Declaring types is one of the first things you

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

> https://github.com/apple/swift-evolution/blob/master/proposals/0161-key-paths.md > > > What is your evaluation of the proposal? +1 in general BUT I absolutely dislike having to escape a key path with `\` which

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

> https://github.com/apple/swift-evolution/blob/master/proposals/0168-multi-line-string-literals.md > > > What is your evaluation of the proposal? +1 My foremost expectation from multiline

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

> On 7 Apr 2017, at 03:28, Rick Mann via swift-evolution > wrote: > > I tend to dislike the backslash as well, but can't suggest a good alternative. > The quirky thing I like about the backslash is that it almost looks like a URL. It might be nice to concatenate

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

> On 9 Apr 2017, at 05:12, Tony Allevato wrote: > > Agreed—I think the parentheses have to go on the outside for this to work. In > this sense, `\Person.mother.age` is an expression that returns a keypath > type, with the idea that the parser is greedy and tries to