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

> On Apr 8, 2017, at 9:12 PM, Tony Allevato via swift-evolution > wrote: > > `\(Foo.bar)` looks like it would try to evaluate `Foo.bar` first and then > compute the "keypath" of that, which doesn't make sense, whereas `(\Foo.bar)` > makes it clear that the keypath

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

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 take as many dotted names that follow. The parentheses halt that if needed, but the

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

On Sat, Apr 8, 2017 at 7:15 PM, Brent Royal-Gordon via swift-evolution < swift-evolution@swift.org> wrote: > On Feb 22, 2017, at 12:24 PM, Jacob Bandes-Storch via swift-evolution < > swift-evolution@swift.org> wrote: > > There were some opinions on Slack that we should simply change `foo` so >

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

+1. We better make sure `equalTo:` is consistent with the label in the `Sequence.all` proposal. -Richard > On Apr 8, 2017, at 19:41, Brent Royal-Gordon via swift-evolution > wrote: > >> On Apr 8, 2017, at 12:44 PM, Xiaodi Wu via swift-evolution >>

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

At one point I was leaning towards a trailing backslash. Now I prefer parenthesis. If parentheses are used should the escape character be outside the parenthesis or inside? For example: let x = (\Person.mother.age).valueType let y = (\Person.mother.age.valueType) vs.

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

> 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, I'm going to have to insist on bikeshedding. `equalTo:` is kind of ugly and has no precedent in the standard library. Similar

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

> On Feb 22, 2017, at 12:24 PM, Jacob Bandes-Storch via swift-evolution > wrote: > > There were some opinions on Slack that we should simply change `foo` so that > it can *only* refer to the nullary version. I think this is the right solution. Eventually we want to

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

> On Apr 6, 2017, at 9:51 AM, Nate Cook wrote: > > Thanks for all your feedback, Brent! One note on this item in particular—if > you specify a default argument for a throws/rethrows closure, you have to use > "try" at the call site even if the default closure argument

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

> On 8 Apr 2017, at 22:18, BJ Homer via swift-evolution > wrote: > > I love the idea of a leading and trailing backslash. It makes it much easier > to read, and handles the "but what if I want to access a property of a > KeyPath?" case really well. > > For

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

Incidentally--and I suppose I will have to repeat myself somewhere else in the likely case that this is not seen by the people who are designing this feature--using the sigil syntax `\foo()` nicely solves the nullary function problem, but we get another ambiguity with the introduction of key paths

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

I love the idea of a leading and trailing backslash. It makes it much easier to read, and handles the "but what if I want to access a property of a KeyPath?" case really well. For example, these two are clearly distinct: let x = \Person.mother.age\.valueType let y =

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

If a lot of people (core team included) agree that the current design is less than ideal...why lock in something so important that can never be changed going forward? Why not get it right and force something source breaking that would improve the language for everyone going forward? The

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

On Fri, Apr 7, 2017 at 11:34 PM, John McCall via swift-evolution < swift-evolution@swift.org> wrote: > > > On Apr 7, 2017, at 8:12 PM, Jakub Suder via swift-evolution < > swift-evolution@swift.org> wrote: > > > > > What is your evaluation of the proposal? > > > > If this is the last option we

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

On Sat, Apr 8, 2017 at 12:01 AM, BJ Homer via swift-evolution < swift-evolution@swift.org> wrote: > If private is required to be tied to types forever and always, then yes, > this proposal should be accepted. Let's be clear: private is not and will never be tied to types. It is tied to

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

+1. Perfect. Let's not bikeshed this and get it done! On Sat, Apr 8, 2017 at 14:04 Ben Cohen via swift-evolution < swift-evolution@swift.org> wrote: > > > Hi swift-evolution, > > Another short proposal related to the Collection algorithms theme, this > time for removing elements in-place from a

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

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: https://github.com/airspeedswift/swift-evolution/blob/1aac5593828941431d1805503865e7a2913d538b/proposals/-RemoveWhere.md

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

Responses inline. Best, Zachary Waldowski z...@waldowski.me On Wed, Apr 5, 2017, at 08:45 PM, Ben Cohen via swift-evolution wrote: > • What is your evaluation of the proposal? Overall, +1. Dictionary and in Set are in need of interaction improvements. However, given the increased

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

I suggested that a while ago. Although I still think it’s the best solution (in addition to the benefits you mentioned, partials could also contain stored properties without making the behavior of extensions inconsistent), it didn’t seem to go over very well on the list, with people balking at

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

> On Apr 6, 2017, at 1:35 PM, Joe Groff via swift-evolution > > wrote: > > https://github.com/apple/swift-evolution/blob/master/proposals/0168-multi-line-string-literals.md > >

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

This seems like a nice compromise, though it introduces a "horizontal" issue of indentation. Not a huge issue IMHO, though I think some people may see it as a downside. For me, it's +1, though. > On Apr 8, 2017, at 2:03 PM, Tino Heth via swift-evolution > wrote: >

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

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 of the existing access modifiers, but refocussing the use of extensions. One such way would be to

[swift-evolution] Enhancing access levels without breaking changes

Imho there is a simple solution to reach the goals of SE-0169 without breaking compatibility: Just allow extensions inside type declarations. class MyVC: UIViewController { private let numberOfSections = 0 extension: UITableViewDataSource { // Skipping the class and assume we

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

What is your evaluation of the proposal? –1 for the proposed solution, but in general I’d myself would want to see multi-line strings in Swift. The current proposal does not cover precision, which could also be desired by developers. My _personal_ view on how I wish multi-line strings do

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

So, +1 for me too. I’m part of the people who didn’t want SE-0025 in the first place, and don’t like any workaround we try to implement to mitigate it, but taking the Core Team decision in account, I feel this is the right thing to do now. If strong scoped variables are needed, it will always

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

Fair enough - in this case, definitely +1 on the current proposal. Kuba On 8 April 2017 at 06:34, John McCall wrote: > > > On Apr 7, 2017, at 8:12 PM, Jakub Suder via swift-evolution < > swift-evolution@swift.org> wrote: > > > > > What is your evaluation of the proposal? >

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

> On 8 Apr 2017, at 2:34 pm, John McCall via swift-evolution > wrote: > >> >> On Apr 7, 2017, at 8:12 PM, Jakub Suder via swift-evolution >> > wrote: >> >>> What is your evaluation of the proposal? >>

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

Type inference sounds nice initially then you face the costs in compilation time and reduced ability to debug and reason about the code months after the fact... and you start to rethink things (not every programmer keeps maintainability over pretty smart haiku code). Sent from my iPhone > On

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

> The Core Team has rejected making such a major change in the interpretation > of 'private'. 'private' will be tied to scopes, now and forever. The only > question is whether extensions of the same type within a file should be > considered part of the same scope for the purposes of

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

> On Apr 7, 2017, at 22:40, Pranshu Goyal via swift-evolution > wrote: > > I agree with the sentiment of the proposal, it does add value to overall > efficiency of swift and make things simpler for the swift team, but as > Matthew said a blanket ban will add noise

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

> On Apr 7, 2017, at 12:21 AM, Daniel Duan via swift-evolution > wrote: > > The cons for doing this are obvious too: the inference makes the language > feels more friendly and is, undoubtedly, a beloved feature for many. This > would be a source breaking change.