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

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

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

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 >

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

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

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"

[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

[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

[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

[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

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

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

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:

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,

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

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

http://www.yelp.com/search?find_desc=liquor+delivery_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

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

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

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!

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

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

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

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

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

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

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 >> > >> wrote: >> >> My one question is, will I be able to

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

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

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 >

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

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

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

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

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

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

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

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

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

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 >

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

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

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

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

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

[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

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

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

[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,

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

[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

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 >

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 >

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

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

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

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

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

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

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

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,

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

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:) →

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

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: > >

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

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: >>>

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

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

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 for the short review cycle, but > we’re right

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

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-0133: Rename `flatten()` to `joined()`" begins now and > runs through July 26. Apologies for the short review cycle, but we’re > right up against

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

On Mon, Jul 25, 2016 at 1:12 AM, Brent Royal-Gordon via swift-evolution < swift-evolution@swift.org> wrote: > > On Jul 24, 2016, at 9:06 PM, Pyry Jahkola via swift-evolution < > swift-evolution@swift.org> wrote: > > > > Another possible choice would be to return .descending whenever either > of

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

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 of source breaking changes for Swift 3. The proposal is available here:

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

> 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. Then we wouldn't see

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

> 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: >> >>>

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

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. The proposal is available here:

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

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 proposal is available here: