Re: [swift-evolution] A shortcut for weakly referencing functions

I run into this a lot and love this idea. > On Apr 1, 2016, at 8:09 AM, Radosław Pietruszewski via swift-evolution > wrote: > > Here’s a pattern I find myself doing quite often: > > 1> class Child { > 2. var onSomeEvent: () -> Void = { } > 3. } > 4> class

Re: [swift-evolution] [Completing Generics] Arbitrary requirements in protocols

> On Apr 11, 2016, at 1:01 AM, Jacob Bandes-Storch via swift-evolution > wrote: > > Doug wrote this in the Completing Generics manifesto, under "Minor > extensions": > > *Arbitrary requirements in protocols > > Currently, a new protocol can inherit from other

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

Aside: `indices` being irregular can be a benefit in the context of auto-complete. > * What is your evaluation of the proposal? +1, very much. As a change from the current model, it’s an across-the-board improvement for me, at least. In a bigger-picture sense I think Swift would be

Re: [swift-evolution] SE-0062 Referencing Objective-C key-paths

> On Apr 7, 2016, at 9:34 PM, Les Pruszynski via swift-evolution > wrote: > > This is my first post on this list so please bear with me. > > I very much like this proposal but what bothers me is this doubling of > valueForKeyPath(#keyPath(xxx) in the signature of

Re: [swift-evolution] [Completing Generics] Arbitrary requirements in protocols

Hi Jacob, I really like the idea of constraining associated types. However I think there could be a much more general solution to this problem by introducing "Partially constrained protocols". I've already created a (almost finished) proposal for another thread which hasn't continued. It

Re: [swift-evolution] Requesting default values for Cocoa/Cocoa Touch APIs

> On Apr 11, 2016, at 4:32 PM, Dave Abrahams via swift-evolution > wrote: > > > on Mon Apr 11 2016, Russ Bishop wrote: > >> Wouldn’t this be the responsibility of UIKit/AppKit teams to provide >> extensions >> that pass the default

Re: [swift-evolution] Requesting default values for Cocoa/Cocoa Touch APIs

on Mon Apr 11 2016, Erica Sadun wrote: > On Apr 11, 2016, at 4:32 PM, Dave Abrahams via swift-evolution > wrote: > > on Mon Apr 11 2016, Russ Bishop wrote: > > Wouldn’t this be the responsibility of UIKit/AppKit teams

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

Thanks for your review, Tony! on Mon Apr 11 2016, Tony Parker wrote: >> On Apr 10, 2016, at 2:41 PM, Chris Lattner via swift-evolution >> wrote: >> >> Hello Swift community, >> >> The review of "A New Model for Collections and Indices"

Re: [swift-evolution] [Completing Generics] Arbitrary requirements in protocols

on Tue Apr 12 2016, Douglas Gregor wrote: > On Apr 11, 2016, at 1:01 AM, Jacob Bandes-Storch via swift-evolution > wrote: > > Doug wrote this in the Completing Generics manifesto, under "Minor > extensions": > >

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

on Mon Apr 11 2016, Brent Royal-Gordon wrote: >>> If these types are for implementation sharing, should they be >>> underscored to discourage their use? Or is the position they occupy in >>> the type hierarchy important because Range and ClosedRange will >>> eventually occupy them? >> >>

Re: [swift-evolution] [Idea] How to eliminate 'optional' protocol requirements

Inline. > On Apr 11, 2016, at 10:03, Dave Abrahams wrote: > > > on Sun Apr 10 2016, Dietmar Planitzer wrote: > >>> On Apr 10, 2016, at 11:46, Dave Abrahams via swift-evolution >> wrote: >>> >>> >>> on Sun Apr 10 2016, Dietmar Planitzer

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

I’m a +1 for the proposal (but as I’ve implemented a bunch of collections recently I’m not sure I’m looking forward to having to update my code to reflect the new pattern ;) But I’m interested by these concerns: > On 12 Apr 2016, at 17:57, plx via swift-evolution >

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

On Tue, Apr 12, 2016 at 4:27 AM, Brent Royal-Gordon wrote: >>> (On the other hand, it might be that I'm conceiving of the purpose of >>> `limitedBy` differently from you—I think of it as a safety measure, but you >>> may be thinking of it specifically as an automatic

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

+1 to Tony’s naming suggestions, myself preferring move(index:by:), move(indexForward:), and move(indexBackward:) as it is the most clear and consistent. As an aside, I am not a fan of the form- prefix, as it feels generic without being self explanatory. I think another word would work better. I

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

on Mon Apr 11 2016, Nate Cook wrote: > Proposal link: > https://github.com/apple/swift-evolution/blob/master/proposals/0065-collections-move-indices.md > > On Apr 11, 2016, at 2:59 PM, Dave Abrahams via swift-evolution > wrote: > > Thanks for your

Re: [swift-evolution] [Completing Generics] Arbitrary requirements in protocols

I'm interested, but I'm by no means claiming I'll have enough time to drive any of the discussion/proposal/implementation. :-( Jacob On Tue, Apr 12, 2016 at 3:07 PM, Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote: > > on Tue Apr 12 2016, Douglas Gregor

[swift-evolution] [Review] Tiny Update: SE-0065 A New Model for Collections and Indices

We realized we neglected to propose this useful API: /// Conversion from one range to another. extension RangeProtocol where Bound : Strideable, Bound.Stride : Integer { /// Creates an instance equivalent to `other`. /// /// - Precondition: an equivalent range is

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

> I want to make a point that avoiding precondition violations by > removing preconditions is not the solution. When you design an API, > it frequently has some constraints on the arguments or on the > execution environment, which, when violated, prevent the API from > performing the operation

[swift-evolution] What about failable literal convertibles?

What about having a protocol for having failable literal convertible initializers for literal optionals? struct AtLeast3 : FailableArrayLiteralConvertible { ... init?(arrayLiteral elements: T...) { guard elements.count >= 3 else { return nil } ... } } var bar:

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

on Tue Apr 12 2016, Brent Royal-Gordon wrote: >>> Huh, that clarifies something. How about the non-`ing` variants? >>> >>> collection.travel(5, from: i) >>> collection.stride(5, from: i) >>> collection.advance(i, by: 5) >> >> Active verb phrases are reserved for methods with

[swift-evolution] Crypto routines as part of the core library

It would seem to me that common crypto routines should become part of the core Swift libraries without having to rely on unknown third party libraries or bridging into the C based CommonCrypto lib. Just some things off the top of my head that we should be able to do easily in pure Swift is

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

> On Apr 12, 2016, at 10:53 PM, Dmitri Gribenko wrote: > > On Tue, Apr 12, 2016 at 8:46 PM, plx via swift-evolution > wrote: >> >> On Apr 12, 2016, at 6:11 PM, Haravikk wrote: >> >> I’m a +1 for the proposal (but

Re: [swift-evolution] [Idea] How to eliminate 'optional' protocol requirements

> On Apr 8, 2016, at 8:53 AM, Shawn Erickson wrote: > > I want to reiterate that I have objective-c code, others have objc code, and > the cocoa, etc. frameworks have code that depend on optional protocol for > things like (but not limited to) delegates. This is of course

Re: [swift-evolution] SE-0062 Referencing Objective-C key-paths

> I very much like this proposal but what bothers me is this doubling of > valueForKeyPath(#keyPath(xxx) in the signature of the function. > > chris.valueForKeyPath(#keyPath(Person.bestFriend.lastName)) // => Groff > > chris > .valueForKeyPath(#keyPath(Person.friends.firstName)) // => ["Joe",

Re: [swift-evolution] SE-0062 Referencing Objective-C key-paths

Key-Paths do support operators and custom functions. How should this work within the context of this proposal? 2016-04-12 11:14 GMT+02:00 Brent Royal-Gordon via swift-evolution < swift-evolution@swift.org>: > > I very much like this proposal but what bothers me is this doubling of >

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

On Mon, Apr 11, 2016 at 9:56 PM, Brent Royal-Gordon via swift-evolution wrote: > So, imagine that we have a type like this in the standard library: > > /// Represents a pre-validated index. A pre-validated index received > from a given collection is >

Re: [swift-evolution] [Proposal]Make .map return the calling collection type

On Tue, Apr 12, 2016 at 1:55 AM, Yogev Sitton via swift-evolution wrote: > Map is great for transforming an array of objects - it is very useful and I > use it a lot. > I would love to use Map with Dictionaries and other collections as well. > > As an example - let’s

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

On Mon, Apr 11, 2016 at 9:56 PM, Brent Royal-Gordon via swift-evolution wrote: > (On the other hand, it might be that I'm conceiving of the purpose of > `limitedBy` differently from you—I think of it as a safety measure, but you > may be thinking of it specifically as

Re: [swift-evolution] [Proposal] Custom operators

No new suggestions have come in 2 days, and so I have created a pull request! Here it is: https://github.com/apple/swift-evolution/pull/253 If new glitches are suddenly discovered, Core team will still have the ability to correct them. So far we have mostly come to consensus. - Anton 2016-04-10

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

> On Apr 12, 2016, at 4:15 AM, Dmitri Gribenko via swift-evolution > wrote: > > On Mon, Apr 11, 2016 at 9:56 PM, Brent Royal-Gordon via > swift-evolution wrote: >> (On the other hand, it might be that I'm conceiving of the purpose of >>