Re: [swift-evolution] [SHORT Review] SE-0132: Rationalizing Sequence end-operation names

On Jul 25, 2016, at 8:17 AM, Jose Cheyo Jimenez wrote: >> On Jul 24, 2016, at 11:10 PM, Chris Lattner via swift-evolution >> wrote: >> >> Hello Swift community, >> >> The review of "SE-0132: Rationalizing Sequence end-operation names" begins >> now and runs through July 26. Apologies for

Re: [swift-evolution] [SHORT Review] SE-0132: Rationalizing Sequence end-operation names

> On Jul 26, 2016, at 3:51 PM, Jose Cheyo Jimenez via swift-evolution > wrote: > > I think we are missing some sort of diff to show the impact of this proposal > similar to what we had for the “grand renaming" The proposal itself shows the impact. * Full list of renamed methods:

Re: [swift-evolution] [Draft] Swift implementation Regex added

> Brent Royal-Gordon: Something to keep in mind when you write your proposal: > At least one member of the core team has expressed a desire for regular > expressions to be deeply integrated into the language, with strong > connections to `case` syntax and destructuring, and a Perl 6-style rethin

Re: [swift-evolution] [SHORT Review] SE-0132: Rationalizing Sequence end-operation names

On Tue, Jul 26, 2016 at 7:56 PM, Boris Wang via swift-evolution < swift-evolution@swift.org> wrote: > We should consider SE-0111. > The label of parameter is not part of function signature anymore. > What are you driving at? Per SE–0111

Re: [swift-evolution] [SHORT Review] SE-0132: Rationalizing Sequence end-operation names

We should consider SE-0111. The label of parameter is not part of function signature anymore. Just a quick peek, what's your first impression for some.first(n) Opt 1: the first element, who's value == n Opt 2: the elements, who's index less than n Ben Rimmington via swift-evolution 于2016年7月27日

Re: [swift-evolution] [Draft] Swift implementation Regex added

> On Jul 25, 2016, at 11:40 AM, Joshua Alvarado via swift-evolution > wrote: > > Okay thanks for taking a look I will have a better implementation ready for > August 1st. Something to keep in mind when you write your proposal: At least one member of the core team has expressed a desire for r

Re: [swift-evolution] [Accepted] SE-0131: Add AnyHashable to the standard library

> On 26 Jul 2016, at 19:52, Chris Lattner via swift-evolution > wrote: > > Proposal Link: > https://github.com/apple/swift-evolution/blob/master/proposals/0131-anyhashable.md > > The review of "SE-0131: Add AnyHashable to the standard library" ran from > Active review July 23…25. The proposa

Re: [swift-evolution] Swift 3.1 vs Swift 4

Wait until August 1st when more will be revealed about post Swift 3 Sent from my iPad > On Jul 26, 2016, at 2:52 PM, Ted F.A. van Gaalen via swift-evolution > wrote: > > Hi Chris (and Core Team) > > > never,never do > > >for Int i = 0; i < what? ;i++ > { > >bottles = glas

Re: [swift-evolution] [SHORT Review] SE-0132: Rationalizing Sequence end-operation names

> On 26 Jul 2016, at 16:15, Dave Abrahams wrote: > >>> b. they are given a recognizable domain-specific notation such as: >>> >>> x.removeSubrange($+n..<) >>> x.removeSubrange(..<$-n) >> >> Does $ represent the start, the end, or either one depending on which >> side of the range we're on? Be

Re: [swift-evolution] [SHORT Review] SE-0132: Rationalizing Sequence end-operation names

On Tue, Jul 26, 2016 at 6:58 PM, Boris Wang wrote: > the single word “first” only means one element， > but “prefix” can means multiple element. > I dispute the former claim. As evidence I cite: • The first four letters of the alphabet are A, B, C, and D. • The first three Presidents of the Unit

Re: [swift-evolution] [SHORT Review] SE-0132: Rationalizing Sequence end-operation names

Whoops, hit reply too soon. Please consider the following inserted in the gap in my last email: 2. We're not comfortable with heavily overloading a property with a bunch > of methods, and didn't want to make `first` and `last` into methods. I am okay with this overload precisely *because* the fu

Re: [swift-evolution] [SHORT Review] SE-0132: Rationalizing Sequence end-operation names

> > * We considered using `first` and `last` as the basis for both >single-element and multiple-element operations (such that `prefix(3)` >would become `first(3)`, etc.), but: > 1. These seemed like distinct functionalities, particularly since > their types are different. I thi

Re: [swift-evolution] [SHORT Review] SE-0132: Rationalizing Sequence end-operation names

the single word “first” only means one element， but “prefix” can means multiple element. Brent Royal-Gordon via swift-evolution 于2016年7月27日 周三03:46写道： > > On Jul 26, 2016, at 8:30 AM, Nevin Brackett-Rozinsky < > nevin.brackettrozin...@gmail.com> wrote: > > > > However, I believe that `first(n)`

Re: [swift-evolution] [SHORT Review] SE-0132: Rationalizing Sequence end-operation names

I think we are missing some sort of diff to show the impact of this proposal similar to what we had for the “grand renaming" > On Jul 26, 2016, at 1:23 PM, Dave Abrahams via swift-evolution > wrote: > > > on Tue Jul 26 2016, Anton Zhilin > wrote: > >> I d

Re: [swift-evolution] [Proposal] Normalize Unicode Identifiers

I'll wait until next week to ping about this again when the stress from Swift 3 has passed. I'll also revise the proposal to clarify about the small code-breaking possibility. As Xiaodi Wu mentioned, this change is highly unlikely to be code-breaking and existing code that would be broken up by

Re: [swift-evolution] [Proposal] Normalize Unicode Identifiers

> On Jul 26, 2016, at 12:22 PM, João Pinheiro via swift-evolution > wrote: > > This proposal [gist > ] is > the result of the discussions from the thread "Prohibit invisible characters > in identifier names >

Re: [swift-evolution] [SHORT Review] SE-0132: Rationalizing Sequence end-operation names

on Tue Jul 26 2016, Anton Zhilin wrote: > I double Nevin on everything he said, especially about incomplete ranges. > > 2016-07-26 21:13 GMT+03:00 Dave Abrahams via swift-evolution < > swift-evolution@swift.org>: > >> >> on Tue Jul 26 2016, Nevin Brackett-Rozinsky < >> nevin.brackettrozinsky-AT-

Re: [swift-evolution] [SHORT Review] SE-0132: Rationalizing Sequence end-operation names

on Mon Jul 25 2016, Garth Snyder wrote: > A warm -0.5 from me, meaning that I agree that this issue is important > to address, and that I concur with many of the particulars. (I agree > that removing is way better than drop, for example.) > > However, I suspect that this approach may open more P

Re: [swift-evolution] [SHORT Review] SE-0132: Rationalizing Sequence end-operation names

on Mon Jul 25 2016, Matthew Johnson wrote: >> >> * What is your evaluation of the proposal? > > I was not totally happy with early drafts of this proposal. The final > draft is a significant improvement. I am mostly +1, with a couple of > minor critiques. > > I think this proposal pushes

Re: [swift-evolution] [SHORT Review] SE-0132: Rationalizing Sequence end-operation names

on Mon Jul 25 2016, Jacob Bandes-Storch wrote: >> >> >> https://github.com/apple/swift-evolution/blob/master/proposals/0132-sequence-end-ops.md >> >> * What is your evaluation of the proposal? >> > > +1 on drop{First,Last}() → removing{First,Last}(). > +1 on drop{First,Last}(_:) → removi

Re: [swift-evolution] [SHORT Review] SE-0132: Rationalizing Sequence end-operation names

> On Jul 26, 2016, at 8:30 AM, Nevin Brackett-Rozinsky > wrote: > > However, I believe that `first(n)` and `last(n)` read more clearly at the > point of use than `prefix(n)` and `suffix(n)`. I've seen this a couple of times. It's something I bring up in "Other alternatives": > * We considere

Re: [swift-evolution] [Proposal] Normalize Unicode Identifiers

+1. Even if it's too late for Swift 3, though, I'd argue that it's highly unlikely to be code-breaking in practice. Any existing code that would get tripped up by this normalization is arguably broken already. On Tue, Jul 26, 2016 at 2:22 PM, João Pinheiro wrote: > This proposal [gist >

Re: [swift-evolution] Prohibit invisible characters in identifier names

I've submitted a draft of the proposal on the thread "Normalize Unicode Identifiers ". Please make any comments and recommendations there. Sincerely, João Pinheiro > On 23 Jun 2016, at 18:30, Chris Lattner wrote: > > >> On Jun 2

[swift-evolution] [Proposal] Normalize Unicode Identifiers

This proposal [gist ] is the result of the discussions from the thread "Prohibit invisible characters in identifier names ". I hope it's still on time for inclu

Re: [swift-evolution] Swift 3.1 vs Swift 4

Hi Chris (and Core Team) never,never do for Int i = 0; i < what? ;i++ { bottles = glass++ * 12 } Seriously, thanks wishing you time tp relax and some tranquility between the hard work! Seriously too: (but for later) Can you help me -after 3.0 is there- wit

Re: [swift-evolution] [SHORT Review] SE-0132: Rationalizing Sequence end-operation names

I double Nevin on everything he said, especially about incomplete ranges. 2016-07-26 21:13 GMT+03:00 Dave Abrahams via swift-evolution < swift-evolution@swift.org>: > > on Tue Jul 26 2016, Nevin Brackett-Rozinsky < > nevin.brackettrozinsky-AT-gmail.com> wrote: > > > * What is your evaluat

Re: [swift-evolution] [SHORT Review] SE-0132: Rationalizing Sequence end-operation names

on Tue Jul 26 2016, Nevin Brackett-Rozinsky wrote: > * What is your evaluation of the proposal? > > “It’s complicated” > > First, I agree with the prevailing sentiment that the incomplete-range > portion ought to be separated and postponed. FWIW, I don't see any evidence that such a se

[swift-evolution] [Accepted] SE-0131: Add AnyHashable to the standard library

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0131-anyhashable.md The review of "SE-0131: Add AnyHashable to the standard library" ran from Active review July 23…25. The proposal has been *accepted*. The feedback on this proposal was quite positive. A few questi

Re: [swift-evolution] Swift 3.1 vs Swift 4

👏 slow 👏 clap 👏 Daniel Duan Sent from my iPhone > On Jul 26, 2016, at 9:14 AM, Michael Ilseman via swift-evolution > wrote: > > I’m sorry, but Whisky for the Core Team is an additive feature and will have > to be deferred until Swift 4. > > > >> On Jul 25, 2016, at 10:37 PM, Charlie Monroe

Re: [swift-evolution] Swift 3.1 vs Swift 4

I’m sorry, but Whisky for the Core Team is an additive feature and will have to be deferred until Swift 4. > On Jul 25, 2016, at 10:37 PM, Charlie Monroe via swift-evolution > wrote: > > I was kind of serious about this. I'll set up a pool on > http://www.payit2.com/for-anything-and-everyth

Re: [swift-evolution] [SHORT Review] SE-0132: Rationalizing Sequence end-operation names

* What is your evaluation of the proposal? “It’s complicated” First, I agree with the prevailing sentiment that the incomplete-range portion ought to be separated and postponed. Second, the proposed renaming of methods brings great consistency. However, I believe that `first(n)` and `las

Re: [swift-evolution] [SHORT Review] SE-0132: Rationalizing Sequence end-operation names

Daniel Duan Sent from my iPhone On Jul 26, 2016, at 5:56 AM, Brent Royal-Gordon via swift-evolution wrote: >> On Jul 25, 2016, at 6:35 PM, Dave Abrahams via swift-evolution >> wrote: >> >> First, though, I have to apologize for those wide tables, since I'm >> listed as a co-author (because

Re: [swift-evolution] [SHORT Review] SE-0132: Rationalizing Sequence end-operation names

on Tue Jul 26 2016, Brent Royal-Gordon wrote: >> On Jul 25, 2016, at 6:35 PM, Dave Abrahams via swift-evolution >> wrote: >> >> First, though, I have to apologize for those wide tables, since I'm >> listed as a co-author (because of a small design contribution). The >> only way I've been able

Re: [swift-evolution] [Proposal] Variadics as Attribute

Hate to have to bump this myself, but I'm still hoping to get more detailed feedback from those that have made negative comments to clarify or clear up any misunderstandings. So far the main argument made against the change is that it's more complex than the problem being solved, however this s

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0131: Add AnyHashable to the standard library

> On Jul 23, 2016, at 3:26 PM, Chris Lattner wrote: > > The review of "SE-0131: Add AnyHashable to the standard library" begins now > and runs through July 25. This proposal is a bit unusual, since it is a late > additive proposal. The reason we need to do something here is as a critical > p

Re: [swift-evolution] [SHORT Review] SE-0133: Rename `flatten()` to `joined()`

> On Jul 25, 2016, at 1:11 PM, Dave Abrahams via swift-evolution > wrote: > > I'm giving the overall idea a +0 and the specific proposal as currently > written a -1, because I think this is a much more complicated bikeshed > than it appears to be on the surface and the proposal doesn't begin to

Re: [swift-evolution] [Accepted] SE-0125: Remove NonObjectiveCBase and isUniquelyReferenced

> On Jul 25, 2016, at 8:47 PM, Chris Lattner via swift-evolution > wrote: > > Proposal Link: > https://github.com/apple/swift-evolution/blob/master/proposals/0125-remove-nonobjectivecbase.md > > The review of "SE-0125: Remove NonObjectiveCBase and isUniquelyReferenced" > ran from Active revie

Re: [swift-evolution] [SHORT Review] SE-0132: Rationalizing Sequence end-operation names

> On Jul 25, 2016, at 6:35 PM, Dave Abrahams via swift-evolution > wrote: > > First, though, I have to apologize for those wide tables, since I'm > listed as a co-author (because of a small design contribution). The > only way I've been able to read them is by looking at the markdown > source,

Re: [swift-evolution] [SHORT Review] SE-0132: Rationalizing Sequence end-operation names

> On Jul 25, 2016, at 1:46 PM, Pyry Jahkola via swift-evolution > wrote: > > I find the introduction of unary operators confusing. I don't think it's good > design that you need to remove a space when moving from the old syntax to the > new one: > > array[array.startIndex ..< someIndex] /

Re: [swift-evolution] [SHORT Review] SE-0132: Rationalizing Sequence end-operation names

On Tue, Jul 26, 2016 at 2:01 AM, Daniel Duan wrote: > > On Jul 25, 2016, at 11:32 PM, David Hart via swift-evolution < > swift-evolution@swift.org> wrote: > > > > On 26 Jul 2016, at 06:50, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > >surface area and leverages the us

Re: [swift-evolution] [SHORT Review] SE-0132: Rationalizing Sequence end-operation names

> On Jul 25, 2016, at 11:32 PM, David Hart via swift-evolution > wrote: > > > > On 26 Jul 2016, at 06:50, Xiaodi Wu via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > >>surface area and leverages the user's understanding of how ranges >>work. >> >>It also implies