Re: [swift-evolution] [Pitch] Retiring `where` from for-in loops

> On Jun 10, 2016, at 1:08 AM, Xiaodi Wu via swift-evolution > wrote: > >> On Thu, Jun 9, 2016 at 9:45 PM, Dany St-Amant wrote: >> >>> Le 9 juin 2016 à 14:55, Xiaodi Wu via swift-evolution >>> a écrit : >>> >>>

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0091: Improving operator requirements in protocols

Proposal link: https://github.com/apple/swift-evolution/blob/master/proposals/0091-improving-operators-in-protocols.md Hi all, > On May 17, 2016, at 8:33 PM, Chris Lattner

Re: [swift-evolution] [Pitch] Retiring `where` from for-in loops

On Thu, Jun 9, 2016 at 9:45 PM, Dany St-Amant wrote: > > Le 9 juin 2016 à 14:55, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> a écrit : > > There have been, in previous threads, several examples given where users > of Swift have found the behavior of `where`

Re: [swift-evolution] [Pitch] Retiring `where` from for-in loops

> On Jun 9, 2016, at 7:15 PM, Erica Sadun via swift-evolution > wrote: > > >> On Jun 8, 2016, at 10:17 PM, Sean Heber > > wrote: >> >> >> On Jun 8, 2016, at 10:51 PM, Erica Sadun via swift-evolution >>

Re: [swift-evolution] [Pitch] Retiring `where` from for-in loops

> On Jun 9, 2016, at 7:16 PM, Erica Sadun wrote: > > >> On Jun 9, 2016, at 11:11 AM, Charlie Monroe >> wrote: >> See my latest post - included results with -Ofast. But still, using filter >> and lazy.filter is 10+% slower, which were the

Re: [swift-evolution] [Pitch] Retiring `where` from for-in loops

> Le 9 juin 2016 à 14:55, Xiaodi Wu via swift-evolution > a écrit : > > There have been, in previous threads, several examples given where users of > Swift have found the behavior of `where` to be misleading and confusing. Sorry Xiaodi, but beside you (on multiple

Re: [swift-evolution] [Proposal] Make non-escaping closures the default

Thanks for the very interesting design discussion so far. It's exactly what I was wanting to see :) I'm going to incorporate some of this in the next draft of the proposal. I'm also going to add that there should be an asUnsafeEscapingClosure(_:) helper that will convert a default/noescape

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

> On Jun 9, 2016, at 3:05 PM, Dave Abrahams wrote: > > > on Thu Jun 09 2016, Matthew Johnson wrote: > >>> On Jun 9, 2016, at 11:42 AM, Dave Abrahams wrote: >>> >>> >>> on Thu Jun 09 2016, Matthew Johnson >> >

Re: [swift-evolution] [Pitch] Retiring `where` from for-in loops

Erica Sadun wrote: > public func timetest(_ note: String, block: () -> Void) { > let date = NSDate() > block() > let timeInterval = NSDate().timeIntervalSince(date) > print(note); print("Elapsed time: \(timeInterval)") > } For performance testing, it might be better to use: *

Re: [swift-evolution] [DRAFT] Regularizing Where Grammar (was Re: Add a while clause to for loops)

> Le 9 juin 2016 à 15:05, Erica Sadun via swift-evolution > a écrit : > > Gist: https://gist.github.com/erica/86f00c1b8ebf45dcf3507ae6ef642b57 > > Regularizing Where grammar > Proposal: TBD > Author: Brent Royal-Gordon, Erica Sadun > Status: TBD > Review manager:

Re: [swift-evolution] [Proposal] Make non-escaping closures the default

> On Jun 9, 2016, at 4:15 PM, Jordan Rose wrote: >> On Jun 9, 2016, at 16:10, John McCall > > wrote: >> >>> On Jun 9, 2016, at 3:43 PM, Jordan Rose via swift-evolution >>>

Re: [swift-evolution] [Proposal] Make non-escaping closures the default

> On Jun 9, 2016, at 16:10, John McCall wrote: > >> On Jun 9, 2016, at 3:43 PM, Jordan Rose via swift-evolution >> > wrote: >> >> I'm against this for library evolution reasons: if someone releases a >> version

Re: [swift-evolution] [Proposal] Make non-escaping closures the default

> On Jun 9, 2016, at 3:43 PM, Jordan Rose via swift-evolution > wrote: > > I'm against this for library evolution reasons: if someone releases a version > of their library that has a non-escaping closure and later discovers it needs > to be escaping, they can't

Re: [swift-evolution] [DRAFT] Regularizing Where Grammar (was Re: Add a while clause to for loops)

After some research I finally get the reference. lol La donna è mobile Qual piuma al vento, Muta d'accento — e di pensiero. Sempre un amabile, Leggiadro viso, In pianto o in riso, — è menzognero. È sempre misero Chi a lei s'affida, Chi le confida — mal cauto il cuore! Pur mai non sentesi Felice

Re: [swift-evolution] [Proposal] Make non-escaping closures the default

> On Jun 9, 2016, at 3:17 PM, Trent Nadeau wrote: > When would be a good time to actual put out a PR to the swift-evolution repo > for this proposal? The feedback so far has been very light, but I'm not sure > if that's because everyone's gearing up for WWDC, if there's

Re: [swift-evolution] [Proposal] Make non-escaping closures the default

I'm against this for library evolution reasons: if someone releases a version of their library that has a non-escaping closure and later discovers it needs to be escaping, they can't change it. IIRC the counterpoint to this is that people were probably implicitly relying on it being

Re: [swift-evolution] [Proposal] Make non-escaping closures the default

When would be a good time to actual put out a PR to the swift-evolution repo for this proposal? The feedback so far has been very light, but I'm not sure if that's because everyone's gearing up for WWDC, if there's little interest, or if it's uncontroversial. On Wed, Jun 8, 2016 at 1:17 PM, John

Re: [swift-evolution] [DRAFT] Regularizing Where Grammar (was Re: Add a while clause to for loops)

> On Jun 9, 2016, at 11:37 PM, Erica Sadun via swift-evolution > wrote: > >> On Jun 9, 2016, at 3:18 PM, Rob Norback wrote: >> >> Def like this change, but Erica I'm wondering what changed your mind about >> the syntax since the last I read you

Re: [swift-evolution] [DRAFT] Regularizing Where Grammar (was Re: Add a while clause to for loops)

On Jun 9, 2016, at 3:18 PM, Rob Norback wrote: > > Def like this change, but Erica I'm wondering what changed your mind about > the syntax since the last I read you still were concerned by the ambiguity > between filtering and exiting. My concerns remain. However, after

Re: [swift-evolution] [DRAFT] Regularizing Where Grammar (was Re: Add a while clause to for loops)

Def like this change, but Erica I'm wondering what changed your mind about the syntax since the last I read you still were concerned by the ambiguity between filtering and exiting. On Thu, Jun 9, 2016 at 1:54 PM Erica Sadun via swift-evolution < swift-evolution@swift.org> wrote: > On Jun 9, 2016,

Re: [swift-evolution] [DRAFT] Regularizing Where Grammar (was Re: Add a while clause to for loops)

> On Jun 9, 2016, at 1:57 PM, Haravikk wrote: > > I think the idea here is for a change from the first to the second of: > > for eachValue in theValues where eachValue.isOdd { … } > for eachValue where eachValue.isOdd in theValues { … } > > I’m kind of

Re: [swift-evolution] Marking sort and sorted with rethrows

> On Jun 9, 2016, at 12:59 PM, Dave Abrahams wrote: > on Thu Jun 09 2016, John McCall wrote: > >>> On Jun 9, 2016, at 9:04 AM, Dave Abrahams via swift-evolution >>> wrote: >>> on Wed Jun 08 2016, Brent Royal-Gordon >>

Re: [swift-evolution] [DRAFT] Regularizing Where Grammar (was Re: Add a while clause to for loops)

I believe this is for case conditionals in for loops only. There is another proposal to remove where from for loops I believe. I am curious, is there any conflict with the reasoning to move where here compared to the accepted SE-0081 "Move where clause to end of declaration"

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

on Thu Jun 09 2016, Matthew Johnson wrote: >> On Jun 9, 2016, at 11:42 AM, Dave Abrahams wrote: >> >> >> on Thu Jun 09 2016, Matthew Johnson > > wrote: >> > On Jun 9, 2016, at 9:55 AM, Dave Abrahams

Re: [swift-evolution] Marking sort and sorted with rethrows

on Thu Jun 09 2016, John McCall wrote: >> On Jun 9, 2016, at 9:04 AM, Dave Abrahams via swift-evolution >> wrote: >> on Wed Jun 08 2016, Brent Royal-Gordon > > wrote: >> I'm not sure that these ideas are consistent with the

Re: [swift-evolution] [DRAFT] Regularizing Where Grammar (was Re: Add a while clause to for loops)

I think the idea here is for a change from the first to the second of: for eachValue in theValues where eachValue.isOdd { … } for eachValue where eachValue.isOdd in theValues { … } I’m kind of split on this for a few reasons. The first is that it doesn’t ready quite as well

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

> On Jun 9, 2016, at 7:29 PM, Thorsten Seitz via swift-evolution > wrote: > > >> Am 09.06.2016 um 00:18 schrieb Dave Abrahams via swift-evolution >> >: >> >> Exactly. But much simpler cases will also

Re: [swift-evolution] [DRAFT] Regularizing Where Grammar (was Re: Add a while clause to for loops)

Can you include an example? I find it hard to visualize for case? pattern where-clause? in expression code-block Thanks, Brandon > On Jun 9, 2016, at 3:05 PM, Erica Sadun via swift-evolution > wrote: > > Gist:

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

> On Jun 9, 2016, at 7:50 PM, Thorsten Seitz via swift-evolution > wrote: > > >> Am 09.06.2016 um 18:49 schrieb Dave Abrahams via swift-evolution >> : >> >> >> on Wed Jun 08 2016, Jordan Rose wrote: >>

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

> On Jun 9, 2016, at 6:49 PM, Dave Abrahams via swift-evolution > wrote: > > > on Wed Jun 08 2016, Jordan Rose wrote: > >>> On Jun 8, 2016, at 13:16, Dave Abrahams via swift-evolution >>> wrote: >>> >>> >>>

Re: [swift-evolution] [DRAFT] Regularizing Where Grammar (was Re: Add a while clause to for loops)

+1 > On Jun 9, 2016, at 1:05 PM, Erica Sadun via swift-evolution > wrote: > > Gist: https://gist.github.com/erica/86f00c1b8ebf45dcf3507ae6ef642b57 > > > Regularizing Where grammar > > Proposal: TBD >

[swift-evolution] [DRAFT] Regularizing Where Grammar (was Re: Add a while clause to for loops)

Gist: https://gist.github.com/erica/86f00c1b8ebf45dcf3507ae6ef642b57 Regularizing Where grammar Proposal: TBD Author: Brent Royal-Gordon , Erica Sadun Status: TBD Review manager: TBD

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

> On Jun 9, 2016, at 4:55 PM, Dave Abrahams via swift-evolution > wrote: > > > on Wed Jun 08 2016, Matthew Johnson > wrote: > >>> On Jun 8, 2016, at 1:33 PM, Dave Abrahams wrote: >>> >>> >>> on Tue Jun 07

Re: [swift-evolution] [Proposal] Add support for compile-time function execution

> Le 9 juin 2016 à 01:41, Alexander Momchilov via swift-evolution > a écrit : > > Preface: I know this is likely a large undertaking to implement, but I think > it's worth it. > > In addition to the typical compiler optimization of constant math > expressions,

Re: [swift-evolution] Enhanced existential types proposal discussion

decided to play with a different syntax https://gist.github.com/lmihalkovic/8aa66542f5cc4592e967bade260477ef still have to formalize it, but it does work for many situations, and is consistent with var a: P1 & P2 > On Jun 9, 2016, at 6:44 PM, Dave Abrahams via swift-evolution >

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

> On Jun 9, 2016, at 9:42 AM, Dave Abrahams via swift-evolution > wrote: > > > If your code has many manual type erasing wrappers corresponding to > protocols with associated types and/or Self requirements that also never > have to trap type mismatches, that would

Re: [swift-evolution] [Pitch] Retiring `where` from for-in loops

There have been, in previous threads, several examples given where users of Swift have found the behavior of `where` to be misleading and confusing. In fact, the first of these proposals began with a question: how does one write arbitrary Boolean assertions after a let binding? The answer (use

Re: [swift-evolution] [Accepted with Revision] SE-0099 Restructuring Condition Clauses

> On Jun 9, 2016, at 12:53 AM, Haravikk wrote: > > >> On 9 Jun 2016, at 02:47, Joe Groff via swift-evolution >> wrote: >> >> comma should remain the condition separator, and the 'where' keyword can be >> retired from its purpose as a

Re: [swift-evolution] [Review] SE-0077: Improved operator declarations

> On Jun 9, 2016, at 12:31 PM, Антон Жилин via swift-evolution > wrote: > > I'm starting to worry about the proposal, too. Any news? > > - Anton They posted: The core team has caught up except for three proposals that have gone through the review period, but

Re: [swift-evolution] [Review] SE-0077: Improved operator declarations

I'm starting to worry about the proposal, too. Any news? - Anton 2016-05-31 1:07 GMT+03:00 Антон Жилин : > I assume that Core team is scheduling a discussion or already discussing > the proposal, and that really takes time in our case. > > In reply to Brent, I think that

Re: [swift-evolution] [Pitch] Retiring `where` from for-in loops

As time goes on, I’m feeling more and more that these consistency proposals are sorely misguided. Frankly, unless the syntax is confusing or misleading, even once the developer has learned the guiding principles of Swift, consistency is not a good argument for change. This proposal is

Re: [swift-evolution] Name disambiguation of computed property/function with same type defined in extensions

> On Jun 9, 2016, at 8:14 PM, Jordan Rose wrote: > >> >> On Jun 9, 2016, at 11:12, L Mihalkovic > > wrote: >> >>> >>> On Jun 9, 2016, at 8:01 PM, Thorsten Seitz >>

Re: [swift-evolution] Name disambiguation of computed property/function with same type defined in extensions

> On Jun 9, 2016, at 11:12, L Mihalkovic wrote: > >> >> On Jun 9, 2016, at 8:01 PM, Thorsten Seitz > > wrote: >> >>> >>> Am 09.06.2016 um 19:46 schrieb L Mihalkovic via swift-evolution >>>

Re: [swift-evolution] Name disambiguation of computed property/function with same type defined in extensions

> On Jun 9, 2016, at 8:01 PM, Thorsten Seitz wrote: > >> >> Am 09.06.2016 um 19:46 schrieb L Mihalkovic via swift-evolution >> >: >> >>> >>> On Jun 9, 2016, at 7:04 PM, Jordan Rose >>

Re: [swift-evolution] Name disambiguation of computed property/function with same type defined in extensions

> On Jun 9, 2016, at 1:01 PM, Thorsten Seitz via swift-evolution > wrote: > > >> Am 09.06.2016 um 19:46 schrieb L Mihalkovic via swift-evolution >> >: >> >>> >>> On Jun 9, 2016, at 7:04 PM, Jordan Rose

Re: [swift-evolution] [Pre-proposal/Question] Exposing the Unboxing Capabilities of AnyIndex (and similar types)

> On 9 Jun 2016, at 17:11, Dave Abrahams wrote: > > > on Thu Jun 09 2016, Haravikk > wrote: > >>> On 8 Jun 2016, at 20:53, Dave Abrahams via swift-evolution >> > wrote:

Re: [swift-evolution] Name disambiguation of computed property/function with same type defined in extensions

> Am 09.06.2016 um 19:46 schrieb L Mihalkovic via swift-evolution > : > >> >> On Jun 9, 2016, at 7:04 PM, Jordan Rose > > wrote: >> >>> >>> On Jun 9, 2016, at 07:35, L. Mihalkovic

Re: [swift-evolution] Name disambiguation of computed property/function with same type defined in extensions

following on my last email: see down > On Jun 9, 2016, at 7:46 PM, L Mihalkovic wrote: > >> >> On Jun 9, 2016, at 7:04 PM, Jordan Rose > > wrote: >> >>> >>> On Jun 9, 2016, at 07:35, L. Mihalkovic

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

> Am 09.06.2016 um 19:24 schrieb Austin Zheng via swift-evolution > : > > On Thu, Jun 9, 2016 at 9:42 AM, Dave Abrahams via swift-evolution > > wrote: > > on Thu Jun 09 2016, Matthew Johnson wrote: > > >

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

> Am 09.06.2016 um 18:49 schrieb Dave Abrahams via swift-evolution > : > > > on Wed Jun 08 2016, Jordan Rose wrote: > >>> On Jun 8, 2016, at 13:16, Dave Abrahams via swift-evolution >>> wrote: >>> >>> >>> on

Re: [swift-evolution] Name disambiguation of computed property/function with same type defined in extensions

> On Jun 9, 2016, at 10:46, L Mihalkovic wrote: > > >> On Jun 9, 2016, at 7:04 PM, Jordan Rose > > wrote: >> >>> >>> On Jun 9, 2016, at 07:35, L. Mihalkovic >>

Re: [swift-evolution] Name disambiguation of computed property/function with same type defined in extensions

> On Jun 9, 2016, at 7:04 PM, Jordan Rose wrote: > >> >> On Jun 9, 2016, at 07:35, L. Mihalkovic > > wrote: >> >> >> On Jun 9, 2016, at 3:27 AM, Jordan Rose via swift-evolution >>

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

> Am 09.06.2016 um 00:18 schrieb Dave Abrahams via swift-evolution > : > > Exactly. But much simpler cases will also either have to trap at > runtime or be prohibited outright: > > func subscript_(c: C, i: C.Index) -> C.Collection.Element { >return c[i] > } >

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

> On Jun 9, 2016, at 11:42 AM, Dave Abrahams wrote: > > > on Thu Jun 09 2016, Matthew Johnson > wrote: > >>> On Jun 9, 2016, at 9:55 AM, Dave Abrahams >> > wrote: >>> >>> >>> on Wed

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

On Thu, Jun 9, 2016 at 9:42 AM, Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote: > > on Thu Jun 09 2016, Matthew Johnson wrote: > > >> > >>> Introducing a language (not library) mechanism that exposes members on > >>> generalized existentials in a way that relies on runtime

Re: [swift-evolution] Marking sort and sorted with rethrows

> On Jun 9, 2016, at 9:04 AM, Dave Abrahams via swift-evolution > wrote: > on Wed Jun 08 2016, Brent Royal-Gordon > wrote: > >>> I'm not sure that these ideas are consistent with the Swift >>> error-handling philosophy, which IIUC

Re: [swift-evolution] [Accepted with Revision] SE-0099 Restructuring Condition Clauses

> On Jun 9, 2016, at 1:04 PM, Christopher Kornher wrote: > > While I preferred a different solution, here, I think that the current “do > not design by committee” process is a good one, and the accepted solution is > definite improvement. A consistent vision is critical to a

Re: [swift-evolution] [Pitch] Retiring `where` from for-in loops

> On Jun 9, 2016, at 11:11 AM, Charlie Monroe wrote: > See my latest post - included results with -Ofast. But still, using filter > and lazy.filter is 10+% slower, which were the suggested alternatives to > `where`. > > I need to correct this misapprehension. My

Re: [swift-evolution] [Pitch] Retiring `where` from for-in loops

> On Jun 8, 2016, at 10:17 PM, Sean Heber wrote: > > > On Jun 8, 2016, at 10:51 PM, Erica Sadun via swift-evolution > > wrote: >> I saw your post on that *after* I finished sending this. Moving `where` next >> to

Re: [swift-evolution] [Pitch] Retiring `where` from for-in loops

> On Jun 9, 2016, at 6:54 PM, Jordan Rose wrote: > > >> On Jun 8, 2016, at 22:19, Charlie Monroe via swift-evolution >> > wrote: >> >>> >>> On Jun 9, 2016, at 5:51 AM, Erica Sadun via swift-evolution >>>

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

> Am 09.06.2016 um 00:13 schrieb Matthew Johnson via swift-evolution > : > > >> On Jun 8, 2016, at 4:47 PM, Austin Zheng > > wrote: >> >> FWIW my opinion is that existentials either shouldn't be allowed to stand

Re: [swift-evolution] [Proposal] Remove force unwrapping in function signature.

Yes, that’s exactly my point. Force unwrapping optionals adds confusion for new users; all too often I see newcomers ending up with the assumption that the force unwrapping takes care of the check for them. On Thu, Jun 9, 2016 at 6:40 AM Spromicky via swift-evolution < swift-evolution@swift.org>

Re: [swift-evolution] [Pitch] Retiring `where` from for-in loops

Didn't originally do it, but added it and here are the results (in seconds): -O none guard: 27.8599720001221 (+0.08%) if-continue: 29.0756570100784 (+4.00%) where: 27.836905002594 (+0.00%) filter: 46.8083620071411 (+68.15%) lazy.filter: 33.3811990022659 (+19.91%) -O fast guard:

Re: [swift-evolution] [Accepted with Revision] SE-0099 Restructuring Condition Clauses

Thanks for the thoughtful feedback :) I partially agree with you on Accepted with Revision...however this could potentially slow down things significantly. I think syntax changes should work the way you describe however as they are more far reaching. I still love Swift, I am just stung by the

Re: [swift-evolution] [Accepted with Revision] SE-0099 Restructuring Condition Clauses

Hi Brandon – I’ll try to speak for one of those ‘newer’ developers (I’ve only got ~1 year of experience in dev work and it’s all part time as a hobby), although my views obviously only reflect my own. I also had a similar ‘gut’ reaction to the approval but after re-reading it several times

Re: [swift-evolution] [Accepted with Revision] SE-0099 Restructuring Condition Clauses

> On 09 Jun 2016, at 18:53, Ethan Eberle via swift-evolution > wrote: > > That said, the one process improvement I have is that proposals should > ideally only be “Accepted” by the core team as it is originally written (or > with relatively minor changes) or

Re: [swift-evolution] Name disambiguation of computed property/function with same type defined in extensions

> On Jun 9, 2016, at 07:35, L. Mihalkovic wrote: > > > On Jun 9, 2016, at 3:27 AM, Jordan Rose via swift-evolution > > wrote: > >> Hi, Paulo. Thanks for bringing this up; it’s definitely an interesting

Re: [swift-evolution] [Accepted with Revision] SE-0099 Restructuring Condition Clauses

While I preferred a different solution, here, I think that the current “do not design by committee” process is a good one, and the accepted solution is definite improvement. A consistent vision is critical to a project as complex as this. It is certainly in Apple’s DNA, and has served it, and

Re: [swift-evolution] Philosophy of Swift

on Wed Jun 08 2016, Brent Royal-Gordon wrote: > Ack, hit Send while I was still typing. > >> Swift does not believe in the no-win scenario. It does not assume > that strong typing must be cumbersome, that memory-safe code must be > slow, or that a language must choose

Re: [swift-evolution] Name disambiguation of computed property/function with same type defined in extensions

> Am 09.06.2016 um 07:55 schrieb L. Mihalkovic : > > > > On Jun 8, 2016, at 9:02 PM, Thorsten Seitz > wrote: > >> >>> Am 07.06.2016 um 22:27 schrieb L Mihalkovic >>

Re: [swift-evolution] Name disambiguation of computed property/function with same type defined in extensions

> Am 09.06.2016 um 03:04 schrieb Jordan Rose : > >> >> On Jun 8, 2016, at 12:02, Thorsten Seitz via swift-evolution >> > wrote: >> >>> >>> Am 07.06.2016 um 22:27 schrieb L Mihalkovic

Re: [swift-evolution] [Accepted with Revision] SE-0099 Restructuring Condition Clauses

Proof? That remains to be seen as I have said. Also, I followed the email thread very closely. What I am saying is that I am not surprised that Brent supports this ultimate proposal not that this is what Brent supported originally. Brandon Sent from my iPad > On Jun 9, 2016, at 12:35 PM, L.

Re: [swift-evolution] extend trailing closure rule

How about using a colon to separate it, to make `completion` look like an argument and to separate it from being a function? Something like this: UIView.animate(withDuration: 0.4) { // animations } completion: { finished in // completion } On Thu, Jun 9, 2016 at 1:06 AM Brent Royal-Gordon via

Re: [swift-evolution] [Accepted with Revision] SE-0099 Restructuring Condition Clauses

Hi Brandon – I’ll try to speak for one of those ‘newer’ developers (I’ve only got ~1 year of experience in dev work and it’s all part time as a hobby), although my views obviously only reflect my own. I also had a similar ‘gut’ reaction to the approval but after re-reading it several times

Re: [swift-evolution] [Pitch] Retiring `where` from for-in loops

> On Jun 8, 2016, at 22:19, Charlie Monroe via swift-evolution > wrote: > >> >> On Jun 9, 2016, at 5:51 AM, Erica Sadun via swift-evolution >> > wrote: >> >> >>> On Jun 8, 2016, at 9:36 PM, Brent

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

on Wed Jun 08 2016, Jordan Rose wrote: >> On Jun 8, 2016, at 13:16, Dave Abrahams via swift-evolution >> wrote: >> >> >> on Wed Jun 08 2016, Thorsten Seitz > >> > > >> wrote:

Re: [swift-evolution] Enhanced existential types proposal discussion

on Thu Jun 09 2016, Douglas Gregor wrote: >> On Jun 8, 2016, at 11:57 AM, Dave Abrahams via swift-evolution > wrote: >> >> >> on Sun Jun 05 2016, Douglas Gregor > wrote: >> > >>> Sent from my iPhone

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

on Thu Jun 09 2016, Matthew Johnson wrote: >> On Jun 9, 2016, at 9:55 AM, Dave Abrahams wrote: >> >> >> on Wed Jun 08 2016, Matthew Johnson > > wrote: >> > On Jun 8, 2016, at 1:33 PM, Dave Abrahams wrote:

Re: [swift-evolution] [Accepted with Revision] SE-0099 Restructuring Condition Clauses

> On Jun 9, 2016, at 6:16 PM, Brandon Knope via swift-evolution > wrote: > > > > Sent from my iPad > > On Jun 9, 2016, at 11:55 AM, Brent Royal-Gordon > wrote: > >>> I believe large syntax changes should have more discussion from more

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

> Am 08.06.2016 um 23:37 schrieb Austin Zheng via swift-evolution > : > > func doSomething(x: T, y: T) { > // Get indexes out of x and use them to index into y > var idx = x.startIndex > while (idx != x.endIndex || idx != y.endIndex) { >

Re: [swift-evolution] Proposal: Filter split extension on Sequence to return tuple of sequences that meet criteria and that do not

This reminds me of something: I *very* often wish the standard library had an analog to `NSIndexSet`. I bring it up b/c it would allow, here, for IMHO a rather nice way to write the *eager* variant of this `filterSplit` (or preferably imho, `partition`, if not for the *other* `partition` out

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

Yes, you were correct. Thanks for spotting that and apologies for not acknowledging you sooner. Austin On Thu, Jun 9, 2016 at 1:13 AM, L. Mihalkovic wrote: > > On Jun 9, 2016, at 8:06 AM, Austin Zheng wrote: > > According to that code

Re: [swift-evolution] [Accepted with Revision] SE-0099 Restructuring Condition Clauses

Sent from my iPad On Jun 9, 2016, at 11:55 AM, Brent Royal-Gordon wrote: >> I believe large syntax changes should have more discussion from more >> developers and not a very small subset of them. The review announcement >> needs to be broader: the swift blog needs to

Re: [swift-evolution] [Draft] Allow multiple conformances to the same protocol

When I said that the problem would exist internally, I meant that there would still be two conflicting associatedtype declarations inside MyType. This can be perfectly solved by conformance-with-renaming. Example: extension MyType : Computer { from Computer rename Internal to Internal1

Re: [swift-evolution] [Pre-proposal/Question] Exposing the Unboxing Capabilities of AnyIndex (and similar types)

on Thu Jun 09 2016, Haravikk wrote: >> On 8 Jun 2016, at 20:53, Dave Abrahams via swift-evolution > wrote: >> >>> on Wed Jun 08 2016, Haravikk > wrote: >>> >>> But those shouldn't be the public names.

Re: [swift-evolution] [Accepted with Revision] SE-0099 Restructuring Condition Clauses

Goodbye semi-column, goodbye multi-let i will mourne you. :( hello reasonable improvement On Jun 9, 2016, at 5:55 PM, Brent Royal-Gordon via swift-evolution wrote: >> I believe large syntax changes should have more discussion from more >> developers and

Re: [swift-evolution] Enhanced existential types proposal discussion

> On Jun 8, 2016, at 11:57 AM, Dave Abrahams via swift-evolution > wrote: > > > on Sun Jun 05 2016, Douglas Gregor > wrote: > >> Sent from my iPhone >> >>> On Jun 5, 2016, at 6:41 PM, Matthew Johnson

Re: [swift-evolution] Marking sort and sorted with rethrows

on Wed Jun 08 2016, Brent Royal-Gordon wrote: >> I'm not sure that these ideas are consistent with the Swift >> error-handling philosophy, which IIUC is very consciously designed *not* >> to support things like file- and database-backed Collections. My >> understanding is that if you have

Re: [swift-evolution] [Pitch] Retiring `where` from for-in loops

Missed pasting this one bit: var value = 0 func doSomething() { // some numeric load value += 1 } > On Jun 9, 2016, at 9:59 AM, Erica Sadun via swift-evolution > wrote: > > My results: > > -Onone (None) > > plain for loop with guard > Elapsed time:

Re: [swift-evolution] [Pitch] Retiring `where` from for-in loops

My results: -Onone (None) plain for loop with guard Elapsed time: 0.0563530325889587 plain for loop with if Elapsed time: 0.0631130337715149 where test Elapsed time: 0.0661619901657104 eager filter test Elapsed time: 0.684610962867737 lazy filter test Elapsed time: 0.640420973300934 Program

Re: [swift-evolution] [Accepted with Revision] SE-0099 Restructuring Condition Clauses

> I believe large syntax changes should have more discussion from more > developers and not a very small subset of them. The review announcement needs > to be broader: the swift blog needs to announce it so more people know. No. Firstly, for those who cannot follow the list—and I can't say I

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

> On Jun 9, 2016, at 9:55 AM, Dave Abrahams wrote: > > > on Wed Jun 08 2016, Matthew Johnson > wrote: > >>> On Jun 8, 2016, at 1:33 PM, Dave Abrahams wrote: >>> >>> >>> on Tue Jun 07 2016, Matthew Johnson wrote:

Re: [swift-evolution] [Draft] Allow multiple conformances to the same protocol

Hmm.. In case we *can* have generic `protocol Computer**{..}` - then yes, it seems like a best solution(generic protocols and using of generic types). As for hypothetical solution without generic protocol, then we need to separate two `Internal` assotiated types (i.e. separate implementation

Re: [swift-evolution] Name disambiguation of computed property/function with same type defined in extensions

> On Jun 9, 2016, at 4:41 PM, Paulo Faria wrote: > >> No matter what, I think many extensions are just a bad outlook on OOD, but >> properly understood, they are great. > > Care to explain a bit more what you mean with this? What is the improper > “understandment” and what

Re: [swift-evolution] [Accepted with Revision] SE-0099 Restructuring Condition Clauses

I never said design by consensus. What I said is that we did not have a broader representation during this review. What we got was a few "top" developers sharing their opinion. To me this is not healthy. We needed more opinions from the top skilled developers to hobbyists. Maybe this wouldn't

Re: [swift-evolution] [Accepted with Revision] SE-0099 Restructuring Condition Clauses

I share the concern of this being a weakness of the process, but I don’t know what the alternative is (besides shutting it down and sealing the sausage-making back inside of Apple where we can’t see it :P) I do think, though, that perhaps in the future maybe there should be a moratorium on

Re: [swift-evolution] [Accepted with Revision] SE-0099 Restructuring Condition Clauses

This kind of attitude is dangerous. Then why even have community reviews? It's obviously to get feedback from the community... Sent from my iPad > On Jun 9, 2016, at 11:07 AM, L Mihalkovic > wrote: > >> On Jun 9, 2016, at 4:59 PM, Brandon Knope

Re: [swift-evolution] Add a while clause to for loops

> On Jun 8, 2016, at 9:23 PM, Brent Royal-Gordon via swift-evolution > wrote: > The original sin here was in connecting the `where` clause to the for loop's > sequence expression, rather than its pattern. If `where` were positioned > right after the loop variable: >

Re: [swift-evolution] [Accepted with Revision] SE-0099 Restructuring Condition Clauses

> On Jun 9, 2016, at 4:59 PM, Brandon Knope wrote: > > I never said design by consensus. What I said is that we did not have a > broader representation during this review. > > What we got was a few "top" developers sharing their opinion. To me this is > not healthy. We needed

Re: [swift-evolution] Philosophy of Swift

on Wed Jun 08 2016, Paul Cantrell wrote: >> On Jun 8, 2016, at 6:13 PM, Dave Abrahams via swift-evolution >> wrote: >> >> on Wed Jun 08 2016, Paul Cantrell wrote: >> >>> The interplay of the first two and the last two is what makes the

  1   2   >