Re: [swift-evolution] Proposal: Allow #if to guard switch case clauses

> On May 11, 2017, at 1:45 AM, Nicholas Maccharoli via swift-evolution > wrote: > I also strongly agree. > > I can think of no strong argument against this, was this intentional at one > point or a compiler bug? The language design of #if is more complex than it is in C: it is part of the la

Re: [swift-evolution] Overriding specific methods when adopting protocols with extension

As the point Allowing subclasses to override requirements satisfied by defaults (*)in the generics manifesto is potentially source breaking in the way the software behaves, is it still on the table for Swift 4? Maybe someone from the core team can comment on this? :-) On Wed, May 10, 2017 at 11:0

Re: [swift-evolution] [Idea] `enum` case count feature

On Wed, May 10, 2017 at 8:52 PM, Saagar Jha via swift-evolution < swift-evolution@swift.org> wrote: > I use a enum (with a Int raw value) for sections in a table view, so > whenever the table view asks for the number of rows I pass in the number of > cases. Currently, I’m doing something like this

Re: [swift-evolution] Proposal: Allow #if to guard switch case clauses

Thank you all! 2017-05-11 16:18 GMT+09:00 John McCall via swift-evolution < swift-evolution@swift.org>: > On May 11, 2017, at 1:45 AM, Nicholas Maccharoli via swift-evolution < > swift-evolution@swift.org> wrote: > I also strongly agree. > > I can think of no strong argument against this, was th

Re: [swift-evolution] Proposal: Allow #if to guard switch case clauses

Just wanted to add that I ran into the #if limitations when trying to port Alamofire to Linux, so any enhancements would be most welcome. There was a point where I had to duplicate an entire class because I couldn't use #if for just the parts I needed. Jon > On May 11, 2017, at 11:57

Re: [swift-evolution] [pitch] Character.unicodeScalars

> On May 10, 2017, at 11:13 PM, Brent Royal-Gordon > wrote: > >> On May 10, 2017, at 4:51 PM, Ben Cohen via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> Add a unicodeScalars property to Character, presending a lazy view of the >> scalars in the character, along similar

Re: [swift-evolution] Swift 4: Support for static libs / modular development.

Until we have native support for this in Xcode (or some sort of SwiftPM integration that would help with this), I found a workaround to allow you to trick Xcode into building static frameworks, so you can sidestep the dynamic framework issues. You can find it here: https://github.com/keith/swift-st

[swift-evolution] [Review] SE-0163 [2]: String Revision: Collection Conformance, C Interop, Transcoding

Hello Swift Community, The review of SE-0163: "String Revision: Collection Conformance, C Interop, Transcoding" begins now and runs through May 15th, 2017. The first version of this proposal was accepted with revisions. The proposed revisions were just a few additions that were publicly request

Re: [swift-evolution] [Review] SE-0163 [2]: String Revision: Collection Conformance, C Interop, Transcoding

Looks good at first glance. Is there a diff showing what’s changed though? Nevin On Thu, May 11, 2017 at 5:39 PM, John McCall via swift-evolution < swift-evolution@swift.org> wrote: > Hello Swift Community, > > The review of SE-0163: "String Revision: Collection Conformance, C > Interop, Transc

Re: [swift-evolution] [pitch] Character.unicodeScalars

> On May 11, 2017, at 12:56 PM, Ben Cohen via swift-evolution > wrote: > > >> On May 10, 2017, at 11:13 PM, Brent Royal-Gordon > > wrote: >> >>> On May 10, 2017, at 4:51 PM, Ben Cohen via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> >>> Ad

Re: [swift-evolution] [pitch] Character.unicodeScalars

> On May 11, 2017, at 13:56, Ben Cohen via swift-evolution > wrote: > > You can use flatMap with a function (Element)->T, and it has the same effect > as map because the function is implicitly converted to (Element)->T? and then > the elements are unwrapped again by the flatMap. [aside] Th

Re: [swift-evolution] [Review] SE-0163 [2]: String Revision: Collection Conformance, C Interop, Transcoding

> On May 11, 2017, at 6:08 PM, Nevin Brackett-Rozinsky via swift-evolution > wrote: > > Looks good at first glance. > > Is there a diff showing what’s changed though? This seems to work: https://github.com/apple/swift-evolution/compare/4cbb1f1fa836496d4bfba95c4b78a9754690956d...master#diff

[swift-evolution] Quick question: Constraint Aliasing

Can anyone give me a rough estimate of how hard (in terms of coding, not in terms of Swift Evolution process) it would be to adopt (1) `extension Set` as an outright alias for `extension Set where Element == ShippingOptions` and (2) `extension [ShippingOptions]` for `extension Array where Eleme

Re: [swift-evolution] [Review] SE-0163 [2]: String Revision: Collection Conformance, C Interop, Transcoding

+1 overall. Is there any hope for a diagnostic to call violations of the issue outlined in the following passage out? any passing of self into an API that takes a concrete String will need to > be rewritten as String(self). If Self is a String then this should > effectively optimize to a no-op, w

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0163 [2]: String Revision: Collection Conformance, C Interop, Transcoding

> On May 11, 2017, at 2:39 PM, John McCall wrote: > What is your evaluation of the proposal? These changes all look like improvements to me. (But I would say that, since I recommended a couple of them in the original review.) I notice that `Unicode.ParseResult`'s cases have lost their `resumptio

Re: [swift-evolution] [Review] SE-0163 [2]: String Revision: Collection Conformance, C Interop, Transcoding

> On May 11, 2017, at 8:47 PM, T.J. Usiyan wrote: > "a closure expression which is immediately caled," Thanks, fixed. (To be clear, that proposal is not part of SE-0163.) John. > > > On Thu, May 11, 2017 at 6:32 PM, John McCall via swift-evolution > mailto:swift-evolution@swift.org>> wrote

Re: [swift-evolution] Quick question: Constraint Aliasing

I have the impression this would be simple enough because it would only live in the parser. But I'm no expert. > On 12 May 2017, at 01:50, Erica Sadun via swift-evolution > wrote: > > Can anyone give me a rough estimate of how hard (in terms of coding, not in > terms of Swift Evolution proces

Re: [swift-evolution] [Review] SE-0163 [2]: String Revision: Collection Conformance, C Interop, Transcoding

I didn't provide feedback on the first iteration because I felt overwhelmed by all the changes. I think I could better comment on them if I could try them out. Is there an Xcode toolchain with those changes implemented? David. > On 11 May 2017, at 23:39, John McCall via swift-evolution > wrot