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

On 26 Jul 2016, at 06:50, Xiaodi Wu via swift-evolution wrote: >>surface area and leverages the user's understanding of how ranges >>work. >> >>It also implies we can replace >> >> x.removingPrefix(n) >> x.removingSuffix(n) >> >>with >> >> x[$+n..<] >> x

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

I was kind of serious about this. I'll set up a pool on http://www.payit2.com/for-anything-and-everything/pool-money-for-a-gift.aspx We should just decide on the target price and choose something from http://www.lovescotch.com - should I submit a PR with a proposal? ;) > On Jul 26, 2016, at 12:

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

Dmitri Gribenko wrote: >> There's one very obscure gotcha with AnyHashable that subclass instances of >> a Hashable base class should be cast to the base type before wrapping into >> AnyHashable, otherwise such wrapped values may break the equivalence law of >> symmetry (`a == b` iff `b == a`). >

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

I’d only +1 this proposal if we can perform an implicit conversion. From SE-0116: > The user model for this type would ideally align with our long-term goal of > supporting Hashable existentials directly, so the type deserves some > short-term compiler support to help us get there. I read tha

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

On Mon, Jul 25, 2016 at 8:35 PM, Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote: > > on Sun Jul 24 2016, Chris Lattner wrote: > > > Hello Swift community, > > > > The review of "SE-0132: Rationalizing Sequence end-operation names" > > begins now and runs through July 26. Ap

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

There’s remove, which is mutating in that it actually removes the elements from the target. removing, on the other hand is nonmutating and basically gives a copy and then removes from the copy. Saagar Jha > On Jul 25, 2016, at 21:21, Boris Wang via swift-evolution > wrote: > > "When the ope

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

"When the operation is naturally described by a verb, use the verb’s imperative for the mutating method and apply the “ed” or “ing” suffix to name its nonmutating counterpart." I known it. But, the "verb" here should be a action will change the object. Not every verb will change the object. Like

[swift-evolution] [Accepted] SE-0127: Cleaning up stdlib Pointer and Buffer Routines

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0127-cleaning-up-stdlib-ptr-buffer.md The review of "[Accepted] SE-0127: Cleaning up stdlib Pointer and Buffer Routines" ran from Active review July 20...24. The proposal has been *accepted with a modification*. This

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

On Mon, Jul 25, 2016 at 1:12 PM, Nate Cook via swift-evolution wrote: >> >> https://github.com/apple/swift-evolution/blob/master/proposals/0131-anyhashable.md > > +1! > > This proposal looks great to me. I only have one nitpick: it looks like > there's a '_Hashable' protocol used in the Di

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

On Mon, Jul 25, 2016 at 1:34 PM, Pyry Jahkola via swift-evolution wrote: > > On 24 Jul 2016, at 01:26, Chris Lattner via swift-evolution > wrote: > > Hello Swift community, > > The review of "SE-0131: Add AnyHashable to the standard library" begins now > and runs through July 25. This proposal i

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

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 review July 19...22. The proposal has been *accepted*. This proposal had significant communit

[swift-evolution] [Accepted] SE-0130: Replace repeating Character and UnicodeScalar forms of String.init

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0130-string-initializers-cleanup.md The review of "SE-0130: Replace repeating Character and UnicodeScalar forms of String.init" ran from Active review July 22…24. The proposal has been *accepted*. There was very litt

[swift-evolution] [Accepted] SE-0128: Change failable UnicodeScalar initializers to failable

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0128-unicodescalar-failable-initializer.md The review of "SE-0128: Change failable UnicodeScalar initializers to failable" ran from Active review July 21…24. The proposal has been *accepted*. Feedback was universally

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

Please read the naming section in Swift API design guidelines https://swift.org/documentation/api-design-guidelines/#naming Daniel Duan Sent from my iPhone > On Jul 25, 2016, at 8:29 PM, Boris Wang via swift-evolution > wrote: > > I am curious about the reason using "removing", > What we are

[swift-evolution] [Rejected] SE-0122: Use colons for subscript declarations

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0122-use-colons-for-subscript-type-declarations.md The review of "SE-0122: Use colons for subscript declarations" ran from July 19…24. The proposal has been *rejected*. The feedback on this proposal from the community

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

I am curious about the reason using "removing", What we are doing is not remove, just selecting some elements from the original collection. ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution

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

on Sun Jul 24 2016, Chris Lattner wrote: > Hello Swift community, > > The review of "SE-0132: Rationalizing Sequence end-operation names" > begins now and runs through July 26. Apologies for the short review > cycle, but we’re right up against the end of source breaking changes > for Swift 3.

Re: [swift-evolution] [Review #3] SE-0117: Allow distinguishing between public access and public overridability

> 2016/07/22 0:33、Chris Lattner via swift-evolution > のメール： > > Hello Swift community, > > The third review of "SE-0117: Allow distinguishing between public access and > public overridability" begins now and runs through July 25. The proposal is > available here: > > > https://github

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

Sly sly manager you are, but I thought popular culture taught us you used automated schnapps IV's for peak productivity ;). http://xkcd.com/323/ Sent from my iPhone > On 25 Jul 2016, at 22:33, Chris Lattner via swift-evolution > wrote: > > >> On Jul 25, 2016, at 12:41 PM, Charlie Monroe

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

on Mon Jul 25 2016, Jacob Bandes-Storch wrote: > On Mon, Jul 25, 2016 at 1:11 PM, Dave Abrahams via swift-evolution < > swift-evolution@swift.org> 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 complicat

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

http://www.yelp.com/search?find_desc=liquor+delivery&find_loc=cupertino,+CA *kof* -- E > On Jul 25, 2016, at 3:33 PM, Chris Lattner via swift-evolution > wrote: > > >> On Jul 25, 2016, at 12:41 PM, Charlie Monroe >> wrote: >> >> I kinda wish that there was a pool where we could all chip i

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

whiskey. Always whiskey. Josh > On Jul 25, 2016, at 2:49 PM, Brandon Knope via swift-evolution > wrote: > > This might need to go through the evolution process: > > Keg of beer or whiskey?!! > > B > >> On Jul 25, 2016, at 5:33 PM, Chris Lattner wrote: >> >> >>> On Jul 25, 2016, at 12:41 P

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

This might need to go through the evolution process: Keg of beer or whiskey?!! B > On Jul 25, 2016, at 5:33 PM, Chris Lattner wrote: > > >> On Jul 25, 2016, at 12:41 PM, Charlie Monroe >> wrote: >> >> I kinda wish that there was a pool where we could all chip in for a keg of >> beer and a

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

On Mon, Jul 25, 2016 at 2:09 PM, David Rönnqvist wrote: > > Haskell calls the general *m (m a) -> m a* function for "join", but also > has a specialized *[[a]] -> [a]* function called "concat". (The function > corresponding to "flatMap" is called "bind" in Haskell (although used as an > operator),

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

> On Jul 25, 2016, at 12:41 PM, Charlie Monroe > wrote: > > I kinda wish that there was a pool where we could all chip in for a keg of > beer and a large bottle of whiskey for the team after the official release of > Swift 3, so that they can celebrate it properly! Given the ambient stress l

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

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 Pandora’s boxes than it closes. Most of my discomf

Re: [swift-evolution] [Revision] [Pitch] Rename `T.Type`

PR closed, we’ll come back for Swift 3.1. ;) --  Adrian Zubarev Sent with Airmail Am 25. Juli 2016 um 23:08:26, Adrian Zubarev (adrian.zuba...@devandartist.com) schrieb: Fixed PR: https://github.com/apple/swift-evolution/pull/468 --  Adrian Zubarev Sent with Airmail Am 25. Juli 2016 um 21

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

> * What is your evaluation of the proposal? +1 for most of the proposal -1 for the slicing subscripts This proposal is well researched, and well written and makes total sense. I totally agree that a renaming is required and I agree with most of the proposal for the exception of the slic

Re: [swift-evolution] [Proposal] Change some collection iterators to use custom types instead of IndexIterator

Submitted the following PR: https://github.com/apple/swift-evolution/pull/469 Michael > On Jul 22, 2016, at 2:35 PM, Michael Gottesman via swift-evolution > wrote: > > Hello everyone! > > Iterators are very important for performance since we use them for for loops. > By default collections

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

>* What is your evaluation of the proposal? -1. I think that there might be something to this idea, but am against the proposal in its current form for the same reasons that have already been stated: flatten has a broader use than just joining sequences/collections, and flatten as a name is

Re: [swift-evolution] [Revision] [Pitch] Rename `T.Type`

Fixed PR: https://github.com/apple/swift-evolution/pull/468 --  Adrian Zubarev Sent with Airmail Am 25. Juli 2016 um 21:35:22, Adrian Zubarev (adrian.zuba...@devandartist.com) schrieb: We’ve submitted a PR. https://github.com/apple/swift-evolution/pull/466 The proposal was refactored complet

Re: [swift-evolution] [Proposal] Formalized Ordering, take 2

> On Jul 25, 2016, at 2:28 PM, Pyry Jahkola via swift-evolution > wrote: > > >> On 25 Jul 2016, at 21:23, Nevin Brackett-Rozinsky >> mailto:nevin.brackettrozin...@gmail.com>> >> wrote: >> >> My one question is, will I be able to write >> `someCollection.sort(.ascending)` and get the expecte

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

> On 25 Jul 2016, at 09:10, 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 the short review cycle, but > we’re right up against the end of sour

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

On Mon, Jul 25, 2016 at 1:11 PM, Dave Abrahams via swift-evolution < swift-evolution@swift.org> 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

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

> On 24 Jul 2016, at 01:26, Chris Lattner via swift-evolution > wrote: > > Hello Swift community, > > 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 w

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

> On Jul 25, 2016, at 3:22 PM, Nate Cook via swift-evolution > wrote: > >> >> https://github.com/apple/swift-evolution/blob/master/proposals/0132-sequence-end-ops.md > > First, a big thanks to Brent for all the work in categorizing, describing, > and justifying all these changes! I'm la

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

on Sun Jul 24 2016, Xiaodi Wu wrote: > On Mon, Jul 25, 2016 at 1:10 AM, Chris Lattner via swift-evolution < > swift-evolution@swift.org> wrote: > >> Hello Swift community, >> >> The review of "SE-0132: Rationalizing Sequence end-operation names" begins >> now and runs through July 26. Apologies

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

> > https://github.com/apple/swift-evolution/blob/master/proposals/0132-sequence-end-ops.md First, a big thanks to Brent for all the work in categorizing, describing, and justifying all these changes! I'm largely in favor of the new method names—several of the renamings lead to better gro

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

on Sun Jul 24 2016, Chris Lattner wrote: > Hello Swift community, > > The review of "SE-0133: Rename `flatten()` to `joined()`" begins now > and runs through July 26. Apologies for the short review cycle, but > we’re right up against the end of source breaking changes for Swift 3. > The proposa

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

> > https://github.com/apple/swift-evolution/blob/master/proposals/0131-anyhashable.md +1! This proposal looks great to me. I only have one nitpick: it looks like there's a '_Hashable' protocol used in the Dictionary extension to get around the limit on generic subscripts. Swift has mana

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

I kinda wish that there was a pool where we could all chip in for a keg of beer and a large bottle of whiskey for the team after the official release of Swift 3, so that they can celebrate it properly! > On Jul 25, 2016, at 9:30 PM, Brandon Knope via swift-evolution > wrote: > > Thanks Chris!

Re: [swift-evolution] [Revision] [Pitch] Rename `T.Type`

We’ve submitted a PR. https://github.com/apple/swift-evolution/pull/466 The proposal was refactored completely. Introduction This proposal removes .Type and .Protocol in favor of two generic-style syntaxes and aligns global type(of:) function (SE–0096) to match the changes. Swift-evolution thr

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

Thanks Chris! I wish you and the team the best week :) Brandon > On Jul 25, 2016, at 2:34 PM, Chris Lattner wrote: > > >> On Jul 25, 2016, at 10:02 AM, Brandon Knope via swift-evolution >> wrote: >> >> +1 for clarification >> >> Swift 4 begins August 1st…does this mean Swift 3.* are only

Re: [swift-evolution] [Proposal] Formalized Ordering, take 2

> On 25 Jul 2016, at 21:23, Nevin Brackett-Rozinsky > wrote: > > My one question is, will I be able to write `someCollection.sort(.ascending)` > and get the expected result? (This could be an additive future direction.) To sort to ascending order, you'd still just call `.sort()` with no argu

Re: [swift-evolution] [Proposal] Formalized Ordering, take 2

> On 25 Jul 2016, at 18:51, Björn Forster wrote: > > Could you please explain for someone as simple minded as me why there is (or > has to be) a difference in the implementation of <, <= and >, >=? > Sorry, but I don't get into my head why there is/has to be a preference for > one side. Could

Re: [swift-evolution] [Proposal] Formalized Ordering, take 2

On Mon, Jul 25, 2016 at 1:52 PM, Stephen Canon via swift-evolution < swift-evolution@swift.org> wrote: > First, this is orthogonal to "adhering to the standard". > isTotallyOrdered( ) provides the total order predicate required by IEEE > 754. The standard has no opinion about whether or not `<=>

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

Okay thanks for taking a look I will have a better implementation ready for August 1st. Alvarado, Joshua > On Jul 25, 2016, at 11:14 AM, Will Field-Thompson wrote: > > The date for Swift 4 proposals is August 1 > (https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160711/024424.

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

> On Jul 25, 2016, at 10:02 AM, Brandon Knope via swift-evolution > wrote: > > +1 for clarification > > Swift 4 begins August 1st…does this mean Swift 3.* are only for bug fixes and > anything that has been approved and has not made it into 3.0? August 1 is when planning for all releases bey

Re: [swift-evolution] [Proposal] Formalized Ordering, take 2

Pyry, this proposal looks great to me. My one question is, will I be able to write `someCollection.sort(.ascending)` and get the expected result? (This could be an additive future direction.) Stephen, what is your rationale for wanting `<=>` to identify NaN values with different payloads as `.equ

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

> On Jul 24, 2016, at 11:10 PM, Chris Lattner via swift-evolution > wrote: > > * What is your evaluation of the proposal? -1. I find the motivation section troubling. It’s simply an assertion that this “should” happen. From reading the rest of the proposed text as well as others review

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

The date for Swift 4 proposals is August 1 ( https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160711/024424.html), so you might want to try posting this again then. On Mon, Jul 25, 2016 at 12:55 PM Brandon Knope via swift-evolution < swift-evolution@swift.org> wrote: > There has be

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

+1 for clarification Swift 4 begins August 1st…does this mean Swift 3.* are only for bug fixes and anything that has been approved and has not made it into 3.0? Brandon > On Jul 25, 2016, at 12:55 PM, Erica Sadun via swift-evolution > wrote: > > Will there be a door of opportunity to propose

[swift-evolution] Swift 3.1 vs Swift 4

Will there be a door of opportunity to propose for Swift 3.1 rather than Swift 4 after 8/1? I've been sitting on `sequence(first, next, while)` (https://github.com/erica/swift/tree/unfold, https://bugs.swift.org/browse/SR-2065) because it's additive. I think it will do a lot to ameliorate the

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

There has been talk on this list of adding a fully featured RegEx feature. It has been pushed back to a later release as the window for Swift 3 is closing Brandon > On Jul 25, 2016, at 12:24 PM, Joshua Alvarado via swift-evolution > wrote: > > My first proposal so take it easy on me :) This i

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

+1 Simple obvious improvement. Scott ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution

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

My first proposal so take it easy on me :) This is a draft so feedback is very welcome and any help. Thank you swiftys. *Introduction* Swift doesn’t have a native implementation of Regex which is included in many other languages. This proposal is a suggestion to introduce a native Regex type i

Re: [swift-evolution] [swift-evolution-announce] [Review #3] SE-0117: Allow distinguishing between public access and public overridability

Agreed as well. This is one of the most contentious topics I’ve seen come across Swift so far. While there may be no stopping the avalanche now as far as implementing the proposal in general (which I remain against, though many of the arguments I’ve heard in favor of it are starting to shake my

Re: [swift-evolution] [Proposal] Formalized Ordering, take 2

Hi Pyry, thanks for all the work you have put into this! Could you please explain for someone as simple minded as me why there is (or has to be) a difference in the implementation of <, <= and >, >=? Sorry, but I don't get into my head why there is/has to be a preference for one side. Could you or

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

> 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 the short review cycle, but > we’re right up against the end of s

[swift-evolution] Getting rid of "..." in variadic functions

Just wanted to ask about the current status — but then saw that there has been a PR already… It's a pity that there hasn't been the time for a detailed answer, as I still think this is one of the best non-trivial proposals so far. So, I guess you're discouraged by the backfire, but afaics, there

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

> What is your evaluation of the proposal? -1 - Certainly `flatten` and `joined` work similarly. I think, however, the concepts behind them are different. When I use `flatten`, I want to make nested monads flat. When I use `joined`, I want to concatenate sequences, mainly `String`s, with a separa

[swift-evolution] [swift-evolution-announce] [Review #3] SE-0117: Allow distinguishing between public access and public overridability

I have to agree with what Scott said. At this point it really does seem a bit rusked just to meet the Swift 3 deadline. There will certainly be breaking changes in Swift 4, 5 etc… so although I understand the reasoning to get as many of these into Swift 3, IMO now it’s just trying to rush the pr

Re: [swift-evolution] [SHORT Review] SE-0134: Rename two UTF8-related properties on String

> On Jul 24, 2016, at 11:18 PM, Chris Lattner via swift-evolution > wrote: > > Hello Swift community, > > The review of "SE-0134: Rename two UTF8-related properties on String" begins > now and runs through July 26. Apologies for the short review cycle, but > we’re right up against the end

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

> On Jul 24, 2016, at 11:10 PM, Chris Lattner via swift-evolution > wrote: > > Hello Swift community, > > The review of "SE-0133: Rename `flatten()` to `joined()`" begins now and runs > through July 26. Apologies for the short review cycle, but we’re right up > against the end of source br

Re: [swift-evolution] [SHORT Review] SE-0134: Rename two UTF8-related properties on String

My suggestion for SE-0134 is to use the `utf8CString` name, overloading for CSignedChar and CUnsignedChar:

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

> * What is your evaluation of the proposal? +1 This makes total sense. I was going to voice my disagreement until I saw that I did not understand what the APIs did because of their names :D The renaming makes things much clearer. > * Is the problem being addressed significant enou

Re: [swift-evolution] [Review #3] SE-0117: Allow distinguishing between public access and public overridability

> On Jul 25, 2016, at 6:38 AM, Brent Royal-Gordon via swift-evolution > wrote: > >> On Jul 21, 2016, at 8:33 AM, Chris Lattner via swift-evolution >> wrote: >> >> * What is your evaluation of the proposal? > > Of the designs offered, I prefer #1, because: > > 1. I'm not convinced that

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

> > * 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 a bit too hard on consistency of “first / last” vs “

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

> On 25 Jul 2016, at 09:10, Chris Lattner via swift-evolution > wrote: > > The review of "SE-0133: Rename `flatten()` to `joined()`" begins now and runs > through July 26. Apologies for the short review cycle, but we’re right up > against the end of source breaking changes for Swift 3. The

Re: [swift-evolution] [SHORT Review] SE-0134: Rename two UTF8-related properties on String

+1. A small but good improvement. It makes even more sense since the documentation for these calls it “null-terminated” (was called “nul-terminated” in the 2.2 documentation). - David > On 25 Jul 2016, at 08:18, Chris Lattner via swift-evolution > wrote: > > Hello Swift community, > > The r

Re: [swift-evolution] [Review #3] SE-0117: Allow distinguishing between public access and public overridability

> On Jul 21, 2016, at 8:33 AM, Chris Lattner via swift-evolution > wrote: > > * What is your evaluation of the proposal? Of the designs offered, I prefer #1, because: 1. I'm not convinced that there's actually any sense in subclassing a class with no open members; it seems to me that an

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

* What is your evaluation of the proposal? +1. It's consistent with the new language guidelines, and though 'flatten' seemed a term-of-art there are multiple arguments here that would clear up things, like the string combination. * Is the problem being addressed significant enough to warra

Re: [swift-evolution] [Review #3] SE-0117: Allow distinguishing between public access and public overridability

> * What is your evaluation of the proposal? +1 In its third revision I like this proposal more. I think “open” is a good keyword for both members and classes. I’m in favor of the first design for open classes. That said, I also acknowledge that subclassing without overriding anything do

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

And try to use overloading more: exclude(index: Int) exclude(part: Range) exclude({closure}) Boris Wang 于2016年7月25日 周一16:09写道： > My suggest: > > * Change removing to exclude. For exam, S.excludeFirst > * Keep shorthand for first and last element > * Change pop to removeXXXCheck. For exam, C.popF

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

I wasn't explicit about that in the proposal, but I was intending that these should be renamed too. There's a minor snag: JoinedSequence already exists. I haven't taken a close look at both implementations yet, but it's possible we could just combine them. On Mon, Jul 25, 2016 at 12:46 AM, Charlie

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

My suggest: * Change removing to exclude. For exam, S.excludeFirst * Keep shorthand for first and last element * Change pop to removeXXXCheck. For exam, C.popFirst =>C.removeFirstCheck Charlie Monroe via swift-evolution 于2016年7月25日 周一15:45写道： > > > On Jul 25, 2016, at 8:10 AM, Chris Lattner via

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

> > > 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}(_:) → removing{Prefix,Suffix}(_:). +1 on drop(while:) → removingPrefix(wh

Re: [swift-evolution] [swift-evolution-announce] [Review #3] SE-0117: Allow distinguishing between public access and public overridability

* What is your evaluation of the proposal? +1 for option 1. * Is the problem being addressed significant enough to warrant a change to Swift? Yes, accidental or thoughtless exposure of non-final classes from 3rd party libraries are something worth addressing. * Does this proposal fit well with

Re: [swift-evolution] [Draft][Proposal] Formalized Ordering

on Sun Jul 24 2016, Brent Royal-Gordon wrote: >> On Jul 24, 2016, at 9:06 PM, Pyry Jahkola via swift-evolution > wrote: >> >> Another possible choice would be to return .descending whenever >> either of the comparands were NaN, while also making <, >, <=, and >> >= return false in such cases.

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

Shouldn't the proposal also mention renaming FlattenCollection, FlattenBidirectionalCollection and FlattenSequence to Joined*(Collection|Sequence)? Or are these going to keep their name? > On Jul 25, 2016, at 8:10 AM, Chris Lattner via swift-evolution > wrote: > > Hello Swift community, > >

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

> On Jul 25, 2016, at 8:10 AM, 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 the short review cycle, but > we’re right up against the end of s

Re: [swift-evolution] [Pitch] Rename `index(of:)`and `index(where:)` to `firstIndex(of:)` and `firstIndex(where:)` respectively

on Sun Jul 24 2016, Brent Royal-Gordon wrote: >> On Jul 24, 2016, at 10:39 PM, Chris Lattner via swift-evolution >> wrote: >> >>> On Jul 24, 2016, at 2:41 PM, Dave Abrahams via swift-evolution >>> wrote: >>> >>> Jose Cheyo Jimenez via swift-evolution writes: > >>> Is your prop

Re: [swift-evolution] [SHORT Review] SE-0134: Rename two UTF8-related properties on String

+1. Seems logical. > On Jul 25, 2016, at 8:18 AM, Chris Lattner via swift-evolution > wrote: > > Hello Swift community, > > The review of "SE-0134: Rename two UTF8-related properties on String" begins > now and runs through July 26. Apologies for the short review cycle, but > we’re right up

Re: [swift-evolution] [swift-evolution-announce] [Review #3] SE-0117: Allow distinguishing between public access and public overridability

-1 to add this proposal for Swift 3.0 I’ve been reading mailing list for the last two reviews of this proposal and discussion turned from “We shouldn’t add this at all” - which was kind of justified to “How actually will it interops with other swift features” - which still has a lot of questio