Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

> • What is your evaluation of the proposal? -1 Code churn, new function name has the same issues as the old one. Benefits small. It is also likely that those suffering with the String collectionifying will have already solved their issues before this update could be introduced. > • Is the

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

> • What is your evaluation of the proposal? -1 Code churn, new function name has the same issues as the old one. Benefits small. It is also likely that those suffering with the String collectionifying will have already solved their issues before this update could be introduced. > • Is the

Re: [swift-evolution] [Review #2] SE-0117: Default classes to be non-subclassable publicly

+1 I'm sold by Brent's reasoning that sealed is the only way to keep options open, both for any given library and for the whole Swift language. I've stayed quiet until now because while philosophically inclined to final by default I was concerned about potential complexity and confusion. I

Re: [swift-evolution] [Review] SE-0121: Remove `Optional` Comparison Operators

On 12/07/2016 19:26, Chris Lattner via swift-evolution wrote: The review of "SE-0121: Remove `Optional` Comparison Operators" begins now and runs through July 19. The proposal is available here:

Re: [swift-evolution] [Review] SE-0113: Add integral rounding functions to FloatingPoint

> The review of "SE-0113: Add integral rounding functions to FloatingPoint" > begins now and runs through July 5. The proposal is available here: > > > https://github.com/apple/swift-evolution/blob/master/proposals/0113-rounding-functions-on-floatingpoint.md > >* What is your

Re: [swift-evolution] [Review] SE-0109: Remove the Boolean protocol

https://github.com/apple/swift-evolution/blob/master/proposals/0109-remove-boolean.md > * What is your evaluation of the proposal? Agree. In extensive Swift use I've never had cause to actively use Boolean rather than Bool. If there is a need to keep it (which I don't see) I think it

[swift-evolution] [Draft Proposal for pre discussion]NS_ENUM's should be considered Open

Can I get some thoughts about this idea to remove undefined behaviour from switch statements when an enum imported from Objective-C has a raw value outside the expected set? The proposal is on my fork and below:

Re: [swift-evolution] [Review] SE-0054: Abolish ImplicitlyUnwrappedOptional type

On 25/03/2016 15:24, Chris Lattner via swift-evolution wrote: Hello Swift community, The review of "Abolish ImplicitlyUnwrappedOptional type" begins now and runs through March 30th. The proposal is available here:

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0053 Remove explicit use of let from Function Parameters

> On Mar 24, 2016, at 6:00 PM, Chris Lattner wrote: > > The review of "Remove explicit use of let from Function Parameters" begins > now and runs through March 27th. The proposal is available here: > > >

Re: [swift-evolution] [Review] SE-0016 - Adding initializers to Int and UInt to convert from UnsafePointer and UnsafeMutablePointer

> On Mar 22, 2016, at 9:35 PM, Chris Lattner via swift-evolution > wrote: > > Hello Swift community, > > The review of "Adding initializers to Int and UInt to convert from > UnsafePointer and UnsafeMutablePointer" begins now and runs through March > 25th. The

Re: [swift-evolution] Asserts should not cause undefined behaviour

om> wrote: >> >> On Dec 28, 2015, at 5:48 AM, Joseph Lord via swift-evolution >> <swift-evolution@swift.org> wrote: >> The documented behaviour of assert and assertionFailure in "disable safety >> checks" builds (still documented as -Ounchecked) i

Re: [swift-evolution] Asserts should not cause undefined behaviour

;> On Dec 31, 2015, at 12:27 PM, Chris Lattner via swift-evolution >>> <swift-evolution@swift.org> wrote: >>> >>> On Dec 28, 2015, at 5:48 AM, Joseph Lord via swift-evolution >>> <swift-evolution@swift.org> wrote: >>>>

[swift-evolution] Asserts should not cause undefined behaviour

I propose that assert and assertionFailure should be no-ops (with branch hints) in unchecked builds as they are in normal release builds rather than resulting in undefined behaviour in the failure condition. I would like to kick off a discussion of this. I found the proposal template useful