Re: [swift-evolution] Final by default for classes and methods

and you get to test betas of future iOS releases anyway, so if something breaks, you'll catch it and release a fix. That assumes that all apps get updated when new OS releases come out, and that's not true. Many apps stop being maintained, but they may have many users, and Apple does whatever

Re: [swift-evolution] [Proposal] allow protocol extensions to contain inheritance clauses

I believe what you're looking for is here under "complete generics" https://github.com/apple/swift-evolution/blob/master/README.md On Fri, Dec 25, 2015 at 8:23 AM Sash Zats wrote: > That would be great! Is there a comprehensive list of features that made > it under the cut? > All

Re: [swift-evolution] [Idea] Expression to retrieve the Objective-C selector of a method

I would add to what Joe mentioned above the fact that the concept of "selector" may not mean a whole lot to developers who are first introduced to Swift without any prior Obj-C or Cocoa experience. Thinking of them as functions I believe avoids introducing complexity in the form of additional

Re: [swift-evolution] [swift-users] WWDC Meetup

I would love to join as well!! I'd like to propose perhaps to plan something alternative to beers to keep it inclusive to members who may not be 21 or like to drink alcohol :) On Mon, Jun 6, 2016 at 3:49 PM Shane S via swift-evolution < swift-evolution@swift.org> wrote: > +1 I'd love to put

Re: [swift-evolution] [swift-corelibs-dev] [swift-users] WWDC Meetup

Hi David! No hard feelings at all :) I just wanted to propose something different, dinner sounds great! Thanks for setting that google forms up! On Tue, Jun 7, 2016 at 5:35 AM David Hart via swift-evolution < swift-evolution@swift.org> wrote: > Hi everybody, > > After receiving a private

Re: [swift-evolution] [Proposal] Remove force unwrapping in function signature.

I agree we could disallow explicitly declaring implicitly unwrapped function parameters, but this will be needed for the clang importer since there will still be many C and ObjC APIs not tagged for nullability. On Wed, Jun 8, 2016 at 2:46 PM Saagar Jha via swift-evolution <

Re: [swift-evolution] Swift 3 vs "additive" proposals

I'll work on a formal proposal for sealed by default :) On Wed, Jun 22, 2016 at 1:43 PM John McCall wrote: > On Jun 22, 2016, at 1:38 PM, Matthew Johnson > wrote: > > On Jun 22, 2016, at 11:48 AM, John McCall wrote: > > On Jun

Re: [swift-evolution] Swift 3 vs "additive" proposals

Hi Matthew. Sorry about that! I just saw your reply. I opened a PR with the proposal already: https://github.com/apple/swift- evolution/pull/376 I would be happy to work with you on improving the proposal. I think your mention to sealed protocols is super interesting, but I think that could be

Re: [swift-evolution] [Proposal] Sealed classes by default

; > On Jun 27, 2016, at 3:40 PM, Javier Soto via swift-evolution < > swift-evolution@swift.org> wrote: > > Hello! > > I sent this as a PR <https://github.com/apple/swift-evolution/pull/376> > on the swift-evolution repo, but we never had any discussion about

[swift-evolution] [Proposal] Sealed classes by default

Hello! I sent this as a PR on the swift-evolution repo, but we never had any discussion about it on-list, besides a long time ago . Here's the first draft of the proposal:

Re: [swift-evolution] [Pitch] Enforce argument order for defaulted parameters

I have never taken advantage of this. In fact, I didn't know this was possible until just now :) and I would've definitely found it confusing to see a function call with "out of order" parameters. On Thu, Mar 31, 2016 at 7:58 AM Developer via swift-evolution < swift-evolution@swift.org> wrote: >

Re: [swift-evolution] Throws, rethrows and declaration-modifiers in function declarations

I see where you're coming from. Without any actual insight into the design of this syntax, I think throws is in the position it is because it relates more to the return type of the function. Aka a `throws -> T` function can either throw ErrorProtocol OR return a T value. On Tue, Jul 19, 2016 at

Re: [swift-evolution] [Proposal] Sealed classes by default

IMO the issue with the argument that we wouldn't be able to "monkey patch" things on sealed classes is that that is already the nature of Swift. The designer of an API can choose to use structs instead of classes, and then there's already no way to "subclass". Moreover, "final" already exists, and

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

My biggest issue with Optional conforming to Comparable is that while a default implementation may sometimes be useful, it may not necessarily be the one you want. In that last example with lastName, if you wanted to change the policy for whether users without last name appear first or last, you'd

Re: [swift-evolution] [Proposal draft] Use obtain let instead if let construction

Based on your examples I think you were thinking about the "guard" keyword, instead of "if"? `If let foo = bar else` is not a valid construction. `if let foo = bar { } else {}` may have been what you meant, but in this case it is clear that this is just like a regular if, combined with unwrapping

Re: [swift-evolution] [Pitch] #error

+1 on adding a compile-time error directive. #error seems like the right syntax as well. I had a maybe nit-picky comment about the proposal though. I think the example may not be ideal, since you could accomplish that compile-time error by annotating the method or class where that code lives with

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

This is very much an issue in Obj-C today. If you have an NS_ENUM defined with cases A, B, and C, this switch is correct: int foo; swith (e) { case A: foo = 0; break; case B: foo = 1; break; case C: foo = 2; break; } (Note the lack of a default case) If that enum is defined in a framework and

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

What doesn't happen today? The issue is not when they ship a new SDK: When rebuilding your app against it, you'll get a warning for a missing case. The problem is when running the app against a newer iOS version with a newer version of the SDK where the enum has a new case. On Sat, Jan 6, 2018 at