Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

Hi Chris, This is great. Thanks for spending time on this! I am in favor of `case #unknown` to only match unknown cases. 1) Would #uknown be available to RawRepresentable structs? 2) How is the #uknown pattern accomplished? Are you suggesting to capture all the compile time known cases so you

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

On Tue, Jan 9, 2018 at 10:10 PM, Chris Lattner wrote: > On Jan 9, 2018, at 3:07 PM, Jose Cheyo Jimenez > wrote: > > Hi Chris, > > > > This is great. Thanks for spending time on this! I am in favor of `case > #unknown` to only match unknown cases. > > >

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

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

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] 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] 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-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] [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] [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] 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] [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] [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] [SHORT Review] SE-0132: Rationalizing Sequence end-operation names

I think we are missing some sort of diff to show the impact of this proposal similar to what we had for the “grand renaming" > On Jul 26, 2016, at 1:23 PM, Dave Abrahams via swift-evolution > wrote: > > > on Tue Jul 26 2016, Anton Zhilin

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

Re: [swift-evolution] [Review #3] SE-0117: Allow distinguishing between public access and public overridability

> * What is your evaluation of the proposal? +1 as before but for the first implementation. I want to like implementation 2 but I really don’t see the need for it because extensions. The only reason for 2 is if the core team thinks that we will never get stored properties can be added

Re: [swift-evolution] Type access level as the default for its members?

> On Jul 22, 2016, at 3:34 AM, Eric-Paul Lecluse via swift-evolution > wrote: > > To illustrate my question below, here are three publicly modified entities: a > struct, an enum and an extension, whose properties lack explicit access > modifiers: > > public

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

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] [Pitch] Unify joined(separator:) and flatten()

[["hey"], ["what"]].joined().joined() // proposed vs [["hey"], ["what"]].flatten().joined(separator: “”) // now I do agree that having two way of doing it now seems odd. [["hey"], ["what"]].joined(separator: []).joined(separator: “”) // now > On Jul 24, 2016, at 5:47 PM, Jacob

Re: [swift-evolution] [Pitch] Unify joined(separator:) and flatten()

Here is a quick example that we would loose. [["hey"], ["what"]].flatten().joined(separator: “") [["hey"], ["what"]].flatten() // ["hey", "what”] The way I think of it is flatten works on array of arrays while joined works on arrays of strings. I guess we could do this too [["hey"],

Re: [swift-evolution] [Pitch] Unify joined(separator:) and flatten()

-1 for this. To me there needs to be a difference between String (which is not a normal collection) and other regular collections. In addition, I really don’t think this proposal has the needed strong support for the change. > On Jul 22, 2016, at 3:41 PM, Jacob Bandes-Storch via

Re: [swift-evolution] [Revision] [Pitch] Rename `T.Type`

I'm finding it really hard to see the advantage of this proposal with out reconciling the possibility of .self going away. I think this should be postponed after .self is reviewed in swift 4. Premature optimization imo. > On Jul 22, 2016, at 3:20 PM, David Hart via swift-evolution >

Re: [swift-evolution] [Revision] [Pitch] Rename `T.Type`

Compiler error： > Missing '.self' for reference to metatype of type 'MyStruct' > > The metatype is from swift it self! > > What the hell was the .self? > > > Jose Cheyo Jimenez via swift-evolution <swift-evolution@swift.org>于2016年7月24日 > 周日04:45写道： >> I

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

Is your proposal going to make the swift3 window? On Jul 24, 2016, at 8:23 AM, Brent Royal-Gordon via swift-evolution wrote: >> On Jul 24, 2016, at 2:58 AM, Tim Vermeulen via swift-evolution >> wrote: >> >> `firstIndex` is completely

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

> On Jul 21, 2016, at 7:15 PM, Duan via swift-evolution > wrote: > > Great proposal. I want to second that areSame may mislead user to think this > is about identity. > > I like areEquivalent() but there may be better names. what about areEqual() ? > > Daniel

Re: [swift-evolution] Type access level as the default for its members?

hat battle is lost for now. > > Félix > >> Le 22 juil. 2016 à 10:14:13, Jose Cheyo Jimenez via swift-evolution >> <swift-evolution@swift.org> a écrit : >> >> >> >> On Jul 22, 2016, at 3:34 AM, Eric-Paul Lecluse via swift-evolution >>

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

> On Jul 27, 2016, at 5:58 AM, Brent Royal-Gordon > wrote: > >> On Jul 26, 2016, at 5:45 PM, Brent Royal-Gordon >> wrote: >> >> I'm working on an implementation (so far I just have `dropFirst` renamed, >> but I've only spent about half an

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] [swift-evolution-announce] [Review #2] SE-0117: Default classes to be non-subclassable publicly

> On Jul 18, 2016, at 1:49 PM, L. Mihalkovic via swift-evolution > wrote: > > Regards > (From mobile) > >> On Jul 18, 2016, at 9:53 PM, Károly Lőrentey via swift-evolution >> wrote: >> >> If people were generally happy with having

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 19, 2016, at 4:13 AM, James Froggatt via swift-evolution > wrote: > > Based on the discussion, I think the real danger of subclassing is unexpected > behaviour - in other words, overriding methods. There doesn't seem to be a > need to penalise subclasses

Re: [swift-evolution] [Review] SE-0122: Use colons for subscript declarations

like that idea. ;( People already abuse subscripts as it is. > L > > > On 20 July 2016 at 14:17, Jose Cheyo Jimenez via swift-evolution > <swift-evolution@swift.org> wrote: >> >> On Jul 20, 2016, at 7:51 AM, Vladimir.S via swift-evolution >> <

Re: [swift-evolution] [Review] SE-0122: Use colons for subscript declarations

> On Jul 20, 2016, at 7:51 AM, Vladimir.S via swift-evolution > wrote: > > +1 to clean up the syntax of subscripts. They acts as properties, not > methods, so it is natural to express them with `:` and not with `->`. > > Actually, I'd prefer additional change to

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

[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-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] [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] [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] 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] [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] [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] 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] A unified error handling mechanism?

Hi Fernando, Some projects use a result type to unify the error handling. https://github.com/antitypical/Result There has been discussions about this and Chris L thinks that we may get a native (constrained) result type at some point.

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] [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] [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] [swift-build-dev] Draft SwiftPM proposal: Multi-package repositories

> On Jan 24, 2017, at 8:31 AM, Daniel Dunbar wrote: > >> >> On Jan 17, 2017, at 2:04 PM, Jose Cheyo Jimenez > > wrote: >> >> Hi Daniel, >> >> I think this is an excellent idea! This would also solve the “local only”

Re: [swift-evolution] final + lazy + fileprivate modifiers

How exactly is the use of scope private harmful? Do you have specific examples when scope private was harmful? > On Feb 18, 2017, at 9:06 PM, Zach Waldowski via swift-evolution > <swift-evolution@swift.org> wrote: > > On Fri, Feb 17, 2017, at 07:52 PM, Jose Cheyo Jimenez v

Re: [swift-evolution] final + lazy + fileprivate modifiers

> On Feb 19, 2017, at 7:16 AM, Matthew Johnson via swift-evolution > wrote: > > > > Sent from my iPad > >> On Feb 19, 2017, at 7:55 AM, David Hart via swift-evolution >> wrote: >> >> >> >>> On 19 Feb 2017, at 10:20, Goffredo

Re: [swift-evolution] [swift-users] Plan to move swift-evolution and swift-users mailing lists to Discourse

Hi Ted, Today I learned about https://esdiscuss.org/ which is like an archiver viewer for disc...@mozilla.org pipermail mailing list All their code is at https://github.com/esdiscuss This still preserves pipermail as the one source of

Re: [swift-evolution] final + lazy + fileprivate modifiers

From Ted. > Relative to Swift 3, the bar for such changes is significantly higher: > > The existing syntax/API being changed must be actively harmful. > The new syntax/API must clearly be better and not conflict with existing > Swift syntax. > There must be a reasonably automatable migration

Re: [swift-evolution] final + lazy + fileprivate modifiers

> On Feb 17, 2017, at 6:10 PM, Matthew Johnson wrote: > > > > Sent from my iPad > > On Feb 17, 2017, at 6:52 PM, Jose Cheyo Jimenez > wrote: > >> >> From Ted. >>> Relative to Swift 3, the bar for such changes is

Re: [swift-evolution] final + lazy + fileprivate modifiers

https://developer.apple.com/swift/blog/?id=11 > On Feb 16, 2017, at 10:05 PM, Charlie Monroe via swift-evolution > wrote: > > How about removing fileprivate, getting Swift 2 meaning of private (as most > people here now suggest) and add additional @protected

Re: [swift-evolution] final + lazy + fileprivate modifiers

itional access levels to > aid with this problem would have to be weighed against a now significantly > more complex access model including file and scoped private. In that sense, > the inclusion of scoped private may indeed be harmful in that it increases > the challenge of much more useful

Re: [swift-evolution] final + lazy + fileprivate modifiers

Sorry to beat this like a drum : How is swift 3 extensibility harmful exactly? Do you have specific examples when extensibility was harmful in a project? This probably deserves its own thread if the examples are substantial. > On Feb 21, 2017, at 1:27 AM, Joanna Carter via

Re: [swift-evolution] final + lazy + fileprivate modifiers

> On Feb 15, 2017, at 1:34 AM, Dietmar Planitzer via swift-evolution > wrote: > > I do like approach #2. It would play well with extensions, look very familiar > to how private works in other main stream languages and it wouldn’t get in > the way of a possible

Re: [swift-evolution] final + lazy + fileprivate modifiers

> On Feb 14, 2017, at 9:31 PM, Chris Lattner via swift-evolution > wrote: > > >> On Feb 14, 2017, at 3:20 AM, David Hart > > wrote: >> >> >> On 14 Feb 2017, at 09:25, Goffredo Marocchi >

Re: [swift-evolution] [swift-build-dev] Draft SwiftPM proposal: Multi-package repositories

Hi Daniel, I think this is an excellent idea! This would also solve the “local only” packages problem. http://stackoverflow.com/questions/40775726/can-i-make-a-local-module-with-the-swift-package-manager

Re: [swift-evolution] Strings in Swift 4

Hi Ben, I just have one concern about the slice of a string being called Substring. Why not StringSlice? The word substring can mean so many things, specially in cocoa. Thank you. Great manifesto. > On Jan 19, 2017, at 8:18 PM, Ben Cohen via swift-evolution >

Re: [swift-evolution] [pitch] Variadic Arguments should accept Arrays

> On Feb 26, 2017, at 9:25 AM, Tino Heth via swift-evolution > wrote: > > I suggest to take a look at the topics "Variadics as an Attribute" and "array > splatting for variadic parameters" and >

Re: [swift-evolution] [pitch] Variadic Arguments should accept Arrays

> On Feb 26, 2017, at 8:26 AM, Derrick Ho via swift-evolution > wrote: > > In swift, a variadic argument can become an array without too much effort. > > func foo(_ va: String...) { >let a: [String] = va > } > > However, it seems odd to me that an array can not

Re: [swift-evolution] [pitch] Variadic Arguments should accept Arrays

> On Feb 27, 2017, at 1:20 PM, Tino Heth <2...@gmx.de> wrote: > >> These is very unfortunate as a solution for “spreading” a collection or >> tuple so that It can be applied to function taking a variadic. >> It makes sense on the declaration site but not on the call site. >> >>

Re: [swift-evolution] [Pitch] Nil struct

Thank for thinking of this. I am not sure on the advantage of having nil as a concrete type. Have you seen this talk? https://realm.io/news/swift-summit-al-skipp-monads/ "The concept of “nil” does not exist in Swift (despite the existence of the keyword nil!)" Does that talk change your

Re: [swift-evolution] [Pitch] Nil struct

> On Nov 8, 2016, at 1:05 PM, Anton Zhilin wrote: > > 2016-11-08 23:43 GMT+03:00 Jose Cheyo Jimenez : > >> Thank for thinking of this. I am not sure on the advantage of having nil as >> a concrete type. >> >> Have you seen this talk? >> >>

Re: [swift-evolution] [Pitch] Replace the ternary operator with an in-language function

> On Oct 25, 2016, at 9:51 PM, Charlotte Angela Tortorella via swift-evolution > wrote: > > Preamble: I've read over the threads that already exist about the ternary > operator and to be honest they're a complete mess without a single fully > formed proposal. >

Re: [swift-evolution] Throws? and throws!

> On Jan 12, 2017, at 5:34 PM, Greg Parker via swift-evolution > wrote: > > >> On Jan 12, 2017, at 4:46 PM, Xiaodi Wu via swift-evolution >> > wrote: >> >>> On Thu, Jan 12, 2017 at 6:27 PM, Jonathan Hull

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

> On Mar 23, 2017, at 11:35 AM, Rien via swift-evolution > wrote: > > >> On 21 Mar 2017, at 08:05, Rien wrote: >> >> +1 > > -1: I have revised my opinion. > > >> >>> • What is your evaluation of the proposal? >> >> Makes the

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

> On Mar 21, 2017, at 1:10 AM, Charlie Monroe via swift-evolution > wrote: > > >> On Mar 21, 2017, at 8:26 AM, Slava Pestov > > wrote: >> >>> >>> On Mar 20, 2017, at 11:07 PM, Charlie Monroe via swift-evolution >>>

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

> On Mar 24, 2017, at 12:32 AM, Rien wrote: > > >>> On 23 Mar 2017, at 21:26, Jose Cheyo Jimenez wrote: >>> >>> >>> On Mar 23, 2017, at 11:35 AM, Rien via swift-evolution >>> wrote: >>> >>> On 21 Mar 2017, at

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

> > What is your evaluation of the proposal? +1 > Is the problem being addressed significant enough to warrant a change to > Swift? Yes. Making scope private be the soft default (private) created much confusion . The incredible overlap that this change created for fileprivate and private is

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

> On Mar 21, 2017, at 11:54 AM, Matthew Johnson via swift-evolution > wrote: > > >> On Mar 21, 2017, at 1:41 PM, David Hart via swift-evolution >> > wrote: >> >> >> >> >> >> Sent from my iPhone >> On

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

> On Mar 21, 2017, at 2:33 PM, Matthew Johnson wrote: > >> >> On Mar 21, 2017, at 4:26 PM, Jose Cheyo Jimenez > > wrote: >> >> >>> On Mar 21, 2017, at 11:54 AM, Matthew Johnson via swift-evolution >>>

Re: [swift-evolution] Enhancing access levels without breaking changes

> On Apr 10, 2017, at 10:22 AM, Tino Heth <2...@gmx.de> wrote: > > >>> I don't buy this argument at all without an objective explanation why the >>> curly braces of extensions should be treated different than the curly >>> braces of types… >> Extensions are not Partials. >>> do you think

Re: [swift-evolution] [Pitch] Remove type-inference for stored property

> On Apr 7, 2017, at 12:21 AM, Daniel Duan via swift-evolution > wrote: > > Hi all, > > In a discussion about inferring parameter types from default value, Slava > brought up some performance problems caused by type inference for stored > properties in side types:

Re: [swift-evolution] Enhancing access levels without breaking changes

> On Apr 10, 2017, at 9:49 AM, Tino Heth via swift-evolution > wrote: > >> But even outside the generated code use cases, it's nice to just be able to >> implement helpers or additional "convenience" conformances in separate files >> named appropriately (like

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

> On Apr 6, 2017, at 4:25 PM, Slava Pestov via swift-evolution > wrote: > > Strong -1. This is a source breaking change, but Swift 4 stage 2 is already > over. I agree with you here. I don't think the proposal will be accepted as is, because of the breaking

Re: [swift-evolution] Enhancing access levels without breaking changes

> On Apr 11, 2017, at 10:45 AM, David Hart via swift-evolution > wrote: > > I don't want to make any change until Chris has been able to chime in. If he > agrees with us, what should be done? > > • Immediate change in the proposal? > • Would it have to go through

Re: [swift-evolution] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

> On Apr 8, 2017, at 5:19 AM, Neil via swift-evolution > wrote: > > I agreed with Charlie, but I think there’s another option. > > The access control problems that both SE-0159 and SE-0169 are attempting to > address can be resolved not by changing the definition

Re: [swift-evolution] Enhancing access levels without breaking changes

> On Apr 9, 2017, at 7:14 PM, Jonathan Hull via swift-evolution > wrote: > > This struck me as a bit odd at first, but the more I think about it, the more > I really like the ability to nest extensions/scopes. The one issue I see is > sticking that public

Re: [swift-evolution] Enhancing access levels without breaking changes

via swift-evolution >>> <swift-evolution@swift.org> a écrit : >>> >>> >>> >>> On 10 Apr 2017, at 05:08, Jose Cheyo Jimenez via swift-evolution >>> <swift-evolution@swift.org> wrote: >>> >>>> >>>

Re: [swift-evolution] [Accepted] SE-0169: Improve Interaction Between `private` Declarations and Extensions

> On Apr 21, 2017, at 8:41 PM, BJ Homer via swift-evolution > wrote: > > The "Access Control" section of the Swift 3 book says the following: >> You can mark an extension with an explicit access-level modifier (for >> example, private extension) to set a new

Re: [swift-evolution] [Accepted] SE-0169: Improve Interaction Between `private` Declarations and Extensions

> On Apr 22, 2017, at 12:30 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote: > >> On Sat, Apr 22, 2017 at 11:51 AM, Jose Cheyo Jimenez via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> >>> On Apr 21, 2017, at 8:41 PM, BJ Homer

Re: [swift-evolution] [Accepted] SE-0169: Improve Interaction Between `private` Declarations and Extensions

> On Apr 22, 2017, at 2:05 PM, Jose Cheyo Jimenez <ch...@masters3d.com> wrote: > > > >> On Apr 22, 2017, at 12:30 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote: >> >>> On Sat, Apr 22, 2017 at 11:51 AM, Jose Cheyo Jimenez via swift-evo

Re: [swift-evolution] [pitch] Variadic Arguments should accept Arrays

g coercion" [swift-evolution] [Pitch] SE-0083 revisited: removing bridging behavior from `as`/`is`/`as?` casts > > > On Feb 27, 2017, at 4:49 PM, Jose Cheyo Jimenez via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > &g

Re: [swift-evolution] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

> On Apr 6, 2017, at 4:10 PM, Douglas Gregor via swift-evolution > wrote: > > What is your evaluation of the proposal? -1 I don't see how this "breaking" change is better than just reverting SE-025. SE-169 complicates private by making it even closer to

  1   2   >