Re: [swift-evolution] [Idea] Wrap switch cases in curly braces

12:31 PM, Saagar Jha <saagarjh...@gmail.com> wrote: > > Was the problem with the ternary conditional operator that nothing could be > found to replace it? That doesn't seem to be the issue here. >> On Mon, Jul 18, 2016 at 00:02 Jose Cheyo Jimenez via swift-evolution >&

Re: [swift-evolution] [Idea] Wrap switch cases in curly braces

I think this proposal is not ""better enough" for it to make sense to diverge from the precedent established by the C family of languages.” And I think the same would go for this “Swift is designed to feel like a member of the C family of languages. Switching keywords away from C precedent

Re: [swift-evolution] [Review] SE-0119: Remove access modifiers from extensions

> On Jul 16, 2016, at 11:16 PM, Xiaodi Wu via swift-evolution > wrote: > >> On Sun, Jul 17, 2016 at 1:07 AM, Adrian Zubarev via swift-evolution >> wrote: >> My first draft had some mistakes related access modifier on extension but >>

Re: [swift-evolution] [Draft] Harmonize access modifiers for extensions

I think you can simplify this proposal by just saying something like this and give a couple of examples that are easy to follow: Disallow explicit public access modifier on non-protocol-conforming type extensions. I think if you only focus on that breaking change then the proposal will have a

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

> On Jul 16, 2016, at 9:18 AM, Taras Zakharko <taras.zakha...@uzh.ch> wrote: > > >> On 16 Jul 2016, at 18:05, Jose Cheyo Jimenez via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> I agree with

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

> * What is your evaluation of the proposal? +1 as before but I do have concerns * Why do open classes need to have also have open superclasses? * I don’t think sealed methods/properties as default is the right default. * If the default was open for

Re: [swift-evolution] [Review] SE-0119: Remove access modifiers from extensions

> On Jul 13, 2016, at 8:46 AM, Xiaodi Wu via swift-evolution > wrote: > > > >> On Wed, Jul 13, 2016 at 4:04 AM, Rod Brown via swift-evolution >> wrote: >> Proposal link: >>

Re: [swift-evolution] [Review] SE-0119: Remove access modifiers from extensions

> * What is your evaluation of the proposal? -1 Strong. This proposal should go back to the drawing board because it is incoherent. This proposal claims to try to remove access modifiers but then also is trying to add them for: > 2.Allow access modifier when

[swift-evolution] [meta] additional input during public reviews

Hi there, I have noticed that on the most controversial reviews there has been a trend of people arguing their specific stance on the proposal beyond the formal response. I am referring to the instances when somebody formally reviews a proposal but keeps responding to other peoples proposals

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

> On Jul 9, 2016, at 10:59 AM, Mark Lacey via swift-evolution > wrote: > > >> On Jul 9, 2016, at 10:47 AM, David Sweeris via swift-evolution >> wrote: >> >> >> >> Sent from my iPhone On Jul 9, 2016, at 11:29, Matthew Johnson via

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

> On Jul 9, 2016, at 7:59 AM, Andre via swift-evolution > wrote: > > Thanks for the thoughtful responses, its appreciated. > >> 2016/07/09 23:30、Matthew Johnson のメール： >> >>> On Jul 9, 2016, at 8:39 AM, Andre wrote: >>>

Re: [swift-evolution] Proposal: Remove the underscore and `in` for `for` loop

How would you build a condition to break if you are ignoring each value ? Unless you are hard coding a condition in which case I would still argue that the proposed shorthand for is less clear than `for _ in` or forEach. > On Jul 4, 2016, at 9:29 PM, Charlie Monroe

Re: [swift-evolution] Proposal: Remove the underscore and `in` for `for` loop

-1 this is why we have collection.forEach{} (1...10).forEach { // do something. } > On Jul 1, 2016, at 12:38 AM, Diego Barros via swift-evolution > wrote: > > When you want a simple `for` loop, for example: > > for _ in 1...10 { > > // do something 10 times > >

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

I almost sent out an email with what you wrote. how about `public( nonfinal )` > - use “public(nonfinal)” to mean “exported out of the module, > subclass/overridable” I think just `open` would be a little bit better. `public( open )` > On Jul 1, 2016, at 11:20 AM, Sean Heber via

Re: [swift-evolution] [Post Swift 3] [Proposal] Introducing `group` mechanism

You are being apprehensive about this. We all want grouping of access modifiers just like c++ has but what you are proposing doesn't seem to be a clear win. In fact I would much rather have plain c++ groupings than group{}. Could you also "replay all" not just the evolution list? It makes it

Re: [swift-evolution] [Discussion] A Problem With SE-0025?

> On Jun 29, 2016, at 4:07 PM, David Hart wrote: > > >> On 29 Jun 2016, at 22:15, Jordan Rose via swift-evolution >> wrote: >> >> There actually is an answer to this, which is that the core team expects >> 'private' to be the common keyword,

Re: [swift-evolution] [Proposal] Revising access modifiers on extensions

> On Jun 28, 2016, at 12:40 PM, Adrian Zubarev via swift-evolution > wrote: > > How do private or fileprivate help extensions in general? > https://github.com/apple/swift-evolution/blob/master/proposals/0025-scoped-access-level.md

Re: [swift-evolution] [Discussion] Terms of Art Swiftification

I would support a rename of filter to the right name. This is a little silly but wouldn't select(…) become selecting(…) with the naming rules? I think where(…) would only make sense if it was lazy by default. There probably needs to be a whole survey of names (seems kinda late for swift 3). I

Re: [swift-evolution] [Proposal] Revising access modifiers on extensions

I would be against removing access modifiers on extensions. I actually don't see anything wrong with the way extensions work with modifiers right now. Consistency for consistency's sake is never a good measurement if it is not addressing a pain point. When ever I extend a swift standard

Re: [swift-evolution] SE-0105: Removing Where Clauses from For-In Loops

> On Jun 24, 2016, at 11:30 AM, Xiaodi Wu via swift-evolution > wrote: > >> On Fri, Jun 24, 2016 at 6:37 AM, William Shipley wrote: >>> On Jun 23, 2016, at 11:04 PM, Xiaodi Wu wrote: >> >>> >>> Not a practitioner of

Re: [swift-evolution] [Review] SE-0105: Removing Where Clauses from For-In Loops

> * What is your evaluation of the proposal? -1. It removes a feature that I love about Swift. When `for;;;` was removed, I thought to my self , we have `where` to help on tricky situations. Removing `where` would make working with for loops more terse. I do not like using guards in my

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

Would sealed classes be able to be (unsafely) casted as non sealed classes? > On Jun 22, 2016, at 9:48 AM, John McCall via swift-evolution > wrote: > >> On Jun 22, 2016, at 9:15 AM, Javier Soto > > wrote: >> How

Re: [swift-evolution] [Review] SE-0103: Make non-escaping closures the default

> * What is your evaluation of the proposal? +1 I think this will help getting safer code by default along with already approved SE-0035 > * Is the problem being addressed significant

Re: [swift-evolution] [Proposal] Make non-escaping closures the default

That proposal was rejected because the swift evolution is not the correct vehicle to drive changes to Apple frameworks. > On Jun 6, 2016, at 8:33 AM, Ben Rimmington via swift-evolution > wrote: > > Trent Nadeau wrote: > >> ### Imported C/Objective-C APIs >> >>

Re: [swift-evolution] [Pitch] Retiring `where` from for-in loops

--1 I think it would be a waste of the community's time to do a formal review when only two people are in favor of this removal. 'for in where' is so useful especially since we don't have for;;; loops anymore. I'd say leave this alone; the majority doesn't want this changed. > On Jun 10,

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

+1 on #3 3. MemoryLayout.size http://i.gifntext.com/29412-number-3-my-lord.gif > On Jun 6, 2016, at 3:37 PM, Dave Abrahams via swift-evolution > wrote: > > > on Mon Jun 06 2016, Nate Cook wrote: > >> I'd like to

Re: [swift-evolution] [Review] SE-0097: Normalizing naming for "negative" attributes

> * What is your evaluation of the proposal? -1. noreturn is a term of art that is googable, renaming will make it obscure imo specially since it is not that common in iOS code. If the core team were to keep `noreturn` then `nonscaping` will be weird, but then if `noescape` became the

Re: [swift-evolution] [Review] SE-0087: Rename lazy to @lazy

> * What is your evaluation of the proposal? -1. Too early to optimize this. I would also be opposed to renaming didSet/willSet to lowercased preemptively because of the sake of renaming. I think property behaviors should declare their own naming and syntax conventions (and be accepted

Re: [swift-evolution] Proposal SE-0009 Reconsideration

Perhaps a better approach to the shadow variables problem is to enable the objc compiler flag -Wshadow to be available in Swift. In the same way a "requiring self" compiler flag should help enforce self on the programer by always showing a warning when the flag is on. > On May 18,

Re: [swift-evolution] [Review] SE-0088: Modernize libdispatch for Swift 3 naming conventions

> On May 11, 2016, at 7:09 AM, Matt Wright via swift-evolution > wrote: > >> >> On May 10, 2016, at 11:52 PM, Jacob Bandes-Storch via swift-evolution >> wrote: >> >> >>* What is your evaluation of the proposal? >> >> I'm

Re: [swift-evolution] [Review] SE-0081: Move where clause to end of declaration

> On May 10, 2016, at 11:51 AM, Chris Lattner via swift-evolution > wrote: > > Hello Swift community, > > The review of "SE-0081: Move where clause to end of declaration" begins now > and runs through May 16. The proposal is available here: > > >

Re: [swift-evolution] [Review] SE-0083: Remove bridging conversion behavior from dynamic casts

> On May 10, 2016, at 11:53 AM, Chris Lattner via swift-evolution > wrote: > > Hello Swift community, > > The review of "SE-0083: Remove bridging conversion behavior from dynamic > casts" begins now and runs through May 16. The proposal is available here: > >

Re: [swift-evolution] [swift-build-dev] [Review] SE-0085: Package Manager Command Names

I like swiftpm > On May 10, 2016, at 9:38 AM, Rick Ballard via swift-build-dev > wrote: > > >> On May 10, 2016, at 8:49 AM, Matthew Johnson via swift-build-dev >> > wrote: >> >> >>> On May 10, 2016,

Re: [swift-evolution] [Pitch] Reducing the bridging magic in dynamic casts

Hi Joe, Would I still be able to cast an AnyObject to a String or Array etc? I am thinking about working with JSON files and using the Apple JSON Parser. Thanks > On May 3, 2016, at 4:50 PM, Joe Groff via swift-evolution > wrote: > > Thanks everyone for the

Re: [swift-evolution] Trial balloon: conforming sizeof, sizeofValue, etc. to naming guidelines

I agree that the names could be more specific but I do agree that putting these methods on `Any` is a good idea. (I am not saying that `Any` should be open to user extensions though.) > On May 2, 2016, at 1:10 PM, Dave Abrahams via swift-evolution > wrote: > > >

Re: [swift-evolution] Mutability for Foundation types in Swift

Hi Tony, Would value types like NSDateFormatterStyle or NSCalendarUnit etc get renamed with out `NS` in Swift ? Would supporting classes to NSDate like NSDateComponents NSDateFormatter etc also get value semantics? Thank you! > On Apr 22, 2016, at 10:18 AM, Tony Parker via swift-evolution

Re: [swift-evolution] [Draft]: Introducing a striding(by:) method on 3.0 ranges

> On Apr 9, 2016, at 1:27 AM, Xiaodi Wu via swift-evolution > wrote: > > On Sat, Apr 9, 2016 at 5:44 AM, Wallacy via swift-evolution > wrote: >> Just as note, i think the sintax should be: >> >> 0...9 >> 0..<9 >> 0>..9 >> 0>.<9 I agree

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

+1 for this. The only reason I was thinking 'external' was because 'module' seems to clash with the identity of the actual module but i am for the order and introducing a new word for module access. > On Mar 14, 2016, at 7:38 PM, Sean Heber via swift-evolution >

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

The word 'external' is growing on me but as the (module access). public (unchanged) external (module access) internal (file access) private (scoped access) module access = has external access from other files in the module. file access = has internal access to current file scope access = has

<    1   2