Re: [swift-evolution] [Pitch] consistent public access modifiers

Hi Matthew, I've read your proposal ideas and most of the discussions on the thread, and I'd like to provide some personal feedback. Swift already has a complicated "access modifier" story so I think we really want a good reason to introduce a new one. And the problem I see is that `closed` ha

Re: [swift-evolution] Strings in Swift 4

Sent from my moss-covered three-handled family gradunza > On Feb 11, 2017, at 5:16 AM, Karl Wagner wrote: > > >>> On 11 Feb 2017, at 04:23, Brent Royal-Gordon wrote: >>> >>> On Feb 10, 2017, at 5:49 PM, Jonathan Hull via swift-evolution >>> wrote: >>> >>> An easier to implement, but slig

Re: [swift-evolution] Strings in Swift 4

Sent from my moss-covered three-handled family gradunza > On Feb 9, 2017, at 3:45 PM, Hooman Mehr wrote: > > >> On Feb 9, 2017, at 3:11 PM, Dave Abrahams wrote: >> >> >> on Thu Feb 09 2017, "Ted F.A. van Gaalen" wrote: >> >>> Hello Shawn >>> Just google with any programming language name

Re: [swift-evolution] Strings in Swift 4

One of the major (so far unstated) goals of the String rethink is to eliminate reasons for people to process textual data outside of String, though. You shouldn't have to use an array of bytes to get performance processing of ASCII, for example. Sent from my moss-covered three-handled family

Re: [swift-evolution] Strings in Swift 4

All of these examples should be efficiently and expressively handled by the pattern matching API mentioned in the proposal. They definitely do not require random access or integer indexing. Sent from my moss-covered three-handled family gradunza > On Feb 9, 2017, at 5:09 PM, Ted F.A. van Gaale

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On 11 Feb 2017, at 20:50, Matthew Johnson via swift-evolution > wrote: > >> >> On Feb 11, 2017, at 12:40 PM, Xiaodi Wu > > wrote: >> >> On Sat, Feb 11, 2017 at 6:41 AM, Matthew Johnson > > wrote: >> >> >> Sent from my iPad >> >>

Re: [swift-evolution] [Pitch] consistent public access modifiers

On Sat, Feb 11, 2017 at 1:50 PM, Matthew Johnson wrote: > > On Feb 11, 2017, at 12:40 PM, Xiaodi Wu wrote: > > On Sat, Feb 11, 2017 at 6:41 AM, Matthew Johnson > wrote: > >> >> >> Sent from my iPad >> >> On Feb 10, 2017, at 9:48 PM, Xiaodi Wu wrote: >> >> On Wed, Feb 8, 2017 at 5:05 PM, Matthe

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On Feb 11, 2017, at 12:40 PM, Xiaodi Wu wrote: > > On Sat, Feb 11, 2017 at 6:41 AM, Matthew Johnson > wrote: > > > Sent from my iPad > > On Feb 10, 2017, at 9:48 PM, Xiaodi Wu > wrote: > >> On Wed, Feb 8, 2017 at 5:05 PM, Matthew

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On Feb 11, 2017, at 7:56 AM, Karl Wagner wrote: > > >> On 11 Feb 2017, at 14:37, Karl Wagner > > wrote: >> >> >>> On 9 Feb 2017, at 00:05, Matthew Johnson via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> >>> I’ve been thinking a lot ab

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On Feb 11, 2017, at 7:37 AM, Karl Wagner wrote: > > >> On 9 Feb 2017, at 00:05, Matthew Johnson via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> I’ve been thinking a lot about our public access modifier story lately in >> the context of both protocols and enums. I be

Re: [swift-evolution] [Pitch] consistent public access modifiers

On Sat, Feb 11, 2017 at 12:53 PM, Matthew Johnson wrote: > > > Sent from my iPad > > On Feb 11, 2017, at 12:44 PM, Xiaodi Wu wrote: > > On Sat, Feb 11, 2017 at 12:42 PM, Matthew Johnson via swift-evolution < > swift-evolution@swift.org> wrote: > >> >> >> Sent from my iPad >> >> > On Feb 11, 2017

Re: [swift-evolution] [Pitch] consistent public access modifiers

Sent from my iPad > On Feb 11, 2017, at 12:44 PM, Xiaodi Wu wrote: > >> On Sat, Feb 11, 2017 at 12:42 PM, Matthew Johnson via swift-evolution >> wrote: >> >> >> Sent from my iPad >> >> > On Feb 11, 2017, at 7:22 AM, Rien wrote: >> > >> > I admit that I have not followed all of this discu

Re: [swift-evolution] [Pitch] consistent public access modifiers

I’m definitely looking forward to this, it’s a highly interesting topic to follow. :) Thank you for all your hard work. --  Adrian Zubarev Sent with Airmail Am 11. Februar 2017 um 19:47:36, Matthew Johnson (matt...@anandabits.com) schrieb: Sent from my iPad On Feb 11, 2017, at 12:38 PM, A

Re: [swift-evolution] [Pitch] consistent public access modifiers

Sent from my iPad > On Feb 11, 2017, at 12:38 PM, Adrian Zubarev via swift-evolution > wrote: > > That makes actually sense to me if we think of it that we never will get any > sub-typing for enums. I’m still undecided on that sub-typing topic about > value types. Just out of curiosity it w

Re: [swift-evolution] [Pitch] consistent public access modifiers

On Sat, Feb 11, 2017 at 12:42 PM, Matthew Johnson via swift-evolution < swift-evolution@swift.org> wrote: > > > Sent from my iPad > > > On Feb 11, 2017, at 7:22 AM, Rien wrote: > > > > I admit that I have not followed all of this discussion, but as far as I > see, we could equally well do this by

Re: [swift-evolution] [Pitch] consistent public access modifiers

Sent from my iPad > On Feb 11, 2017, at 7:22 AM, Rien wrote: > > I admit that I have not followed all of this discussion, but as far as I see, > we could equally well do this by calling “not-open” enum’s “final”. > It seems like a better fit to me. That is actually not a very good fit at all

Re: [swift-evolution] [Pitch] consistent public access modifiers

On Sat, Feb 11, 2017 at 6:41 AM, Matthew Johnson wrote: > > > Sent from my iPad > > On Feb 10, 2017, at 9:48 PM, Xiaodi Wu wrote: > > On Wed, Feb 8, 2017 at 5:05 PM, Matthew Johnson via swift-evolution < > swift-evolution@swift.org> wrote: > >> I’ve been thinking a lot about our public access mo

Re: [swift-evolution] [Pitch] consistent public access modifiers

That makes actually sense to me if we think of it that we never will get any sub-typing for enums. I’m still undecided on that sub-typing topic about value types. Just out of curiosity it would be interesting to hear from the core team if this would be a future direction for Swift or not, be it

Re: [swift-evolution] [Pitch] consistent public access modifiers

Sent from my iPad > On Feb 11, 2017, at 12:30 PM, Xiaodi Wu wrote: > > I think Matthew's point (with which I agree) is that, as enums are sum types, > adding or removing cases is akin to subclassing. You can extend a public enum > by adding methods just like you can extend a public class. Bu

Re: [swift-evolution] [Pitch] consistent public access modifiers

I think Matthew's point (with which I agree) is that, as enums are sum types, adding or removing cases is akin to subclassing. You can extend a public enum by adding methods just like you can extend a public class. But just as you cannot subclass a public class, you should not be able to add or rem

Re: [swift-evolution] for in? optionalCollection {

let test: [Int]? = nil for b in test ?? [] where b != 42 { Print(b) } I don't think you need new syntax since what you want can be accomplished quite succinctly already On Sat, Feb 11, 2017 at 8:18 AM Anton Zhilin via swift-evolution < swift-evolution@swift.org> wrote: for i in test ?? [] {

Re: [swift-evolution] [Pitch] consistent public access modifiers

I have to correct myself here and there. … which would be extensible if that feature might be added to swift one day. Again, I see open only as a contract to allow sub-typing, conformances and overriding to the client, where extensibility of a type a story of it’s own. --  Adrian Zubarev Sent

Re: [swift-evolution] [Pitch] consistent public access modifiers

It wasn’t my intention to drive to far way off topic with this. The major point of my last bike shedding was that I have to disagree with you about the potential future open enum vs. public enum and closed enum. public today does not add any guarantee to prevent the client from extending your t

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On 11 Feb 2017, at 14:37, Karl Wagner wrote: > > >> On 9 Feb 2017, at 00:05, Matthew Johnson via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> I’ve been thinking a lot about our public access modifier story lately in >> the context of both protocols and enums. I belie

Re: [swift-evolution] [Pitch] consistent public access modifiers

> On 9 Feb 2017, at 00:05, Matthew Johnson via swift-evolution > wrote: > > I’ve been thinking a lot about our public access modifier story lately in the > context of both protocols and enums. I believe we should move further in the > direction we took when introducing the `open` keyword. I

Re: [swift-evolution] [Pitch] consistent public access modifiers

I admit that I have not followed all of this discussion, but as far as I see, we could equally well do this by calling “not-open” enum’s “final”. It seems like a better fit to me. Regards, Rien Site: http://balancingrock.nl Blog: http://swiftrien.blogspot.com Github: http://github.com/Balancingr

Re: [swift-evolution] for in? optionalCollection {

for i in test ?? [] { print(i) } For a more general solution, we could add Optional.flatten() to support optional sequences: for i in test.flatten() { print(i) } ​ ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.o

Re: [swift-evolution] Strings in Swift 4

> On 11 Feb 2017, at 04:23, Brent Royal-Gordon wrote: > >> On Feb 10, 2017, at 5:49 PM, Jonathan Hull via swift-evolution >> wrote: >> >> An easier to implement, but slightly less useful approach, would be to have >> methods which take an array of indexes along with the proposed change, and

Re: [swift-evolution] [Pitch] consistent public access modifiers

Sent from my iPad > On Feb 11, 2017, at 4:25 AM, Adrian Zubarev via swift-evolution > wrote: > > I’m probably better describing things with some bikeshedding code, but feel > free to criticize it as much as you’d like. > > //===- Module A -===// > @closed pub

Re: [swift-evolution] for in? optionalCollection {

Ah I see you point a bit better. But I don't agree with your example, since it can be easily expressed with test?.prefix(while: { $0 != 42}).forEach { i in print(i) } But arguing about examples is besides the point, I would like to stop here. I have a question for you. How do you think we c

Re: [swift-evolution] [Pitch] consistent public access modifiers

Sent from my iPad > On Feb 10, 2017, at 9:48 PM, Xiaodi Wu wrote: > >> On Wed, Feb 8, 2017 at 5:05 PM, Matthew Johnson via swift-evolution >> wrote: >> I’ve been thinking a lot about our public access modifier story lately in >> the context of both protocols and enums. I believe we should

Re: [swift-evolution] [Pitch] consistent public access modifiers

Sent from my iPad > On Feb 10, 2017, at 9:35 PM, Xiaodi Wu wrote: > >> On Fri, Feb 10, 2017 at 9:15 AM, Matthew Johnson >> wrote: >> >>> On Feb 10, 2017, at 1:06 AM, Xiaodi Wu wrote: >>> On Thu, Feb 9, 2017 at 9:57 AM, Matthew Johnson wrote: > On Feb 8, 2017, at 5:48

Re: [swift-evolution] for in? optionalCollection {

> I don't think this use case warrants a syntax change since it can already be > expressed quite elegantly with > > let test: [Int]? = nil > > test?.forEach { i in > print(i) > } > What about just use > > test?.forEach { print($0) } This works for the simple example, but it isn't as power

Re: [swift-evolution] Warning when omitting default case for imported enums

Sent from my iPad > On Feb 11, 2017, at 5:11 AM, Tino Heth via swift-evolution > wrote: > > >> Closed would not be an access level, just an attribute orthogonal to the >> others. > As Xiaodi pointed out, there's still no agreement on that — so basically I'm > saying that I prefer your inte

Re: [swift-evolution] array splatting for variadic parameters

> func f(_ args: [Int]) { > // Some implementation ... > } > > func f(_ args: Int…) { > f(args) > } > > Some people also advocate (myself generally included) that one should prefer > the signature explicitly marking args as an array, as the syntactic overhead > of wrapping the arguments wi

Re: [swift-evolution] for in? optionalCollection {

What about just use test?.forEach { print($0) } Zhaoxin On Sat, Feb 11, 2017 at 7:48 PM, Tino Heth via swift-evolution < swift-evolution@swift.org> wrote: > This one started over at swift-users, with a question on how to deal with > looping over containers that may be nil. > > Imho the beauty o

Re: [swift-evolution] for in? optionalCollection {

I don't think this use case warrants a syntax change since it can already be expressed quite elegantly with let test: [Int]? = nil test?.forEach { i in print(i) } Maybe "in?" could be used instead of let test: [Int?] = [0,1,nil,3] for case let i? in test { print(i) } ? > On 11 Feb 2

Re: [swift-evolution] Warning when omitting default case for imported enums

Sent from my iPad > On Feb 10, 2017, at 9:22 PM, Xiaodi Wu via swift-evolution > wrote: > >> On Fri, Feb 10, 2017 at 7:23 PM, Slava Pestov via swift-evolution >> wrote: >> >>> On Feb 10, 2017, at 8:55 AM, Tino Heth <2...@gmx.de> wrote: >>> > I'm not sure if I like the concept of havin

[swift-evolution] for in? optionalCollection {

This one started over at swift-users, with a question on how to deal with looping over containers that may be nil. Imho the beauty of the feature is that it's simple enough to be explained in the subject line, but here is the "long" story: let test: [Int]? = nil // this is possible now if let

Re: [swift-evolution] Warning when omitting default case for imported enums

> Closed would not be an access level, just an attribute orthogonal to the > others. As Xiaodi pointed out, there's still no agreement on that — so basically I'm saying that I prefer your interpretation, because imho five access levels are already a alarmingly high number. > What do you mean b

Re: [swift-evolution] [Pitch] consistent public access modifiers

I’m probably better describing things with some bikeshedding code, but feel free to criticize it as much as you’d like. //===- Module A -===// @closed public enum A { case a } extension A { case aa // error, because enum is closed } public func foo(a: A)