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

> On Feb 13, 2017, at 10:14 AM, Adrian Zubarev via swift-evolution > wrote: > > Is that assumption correct? > > // Module A > public protocol SQLiteValue { > init(statement: SQLiteStatement, columnAt index: Int) throws > func bind(to statement:

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

> On Feb 13, 2017, at 10:19 AM, Karl Wagner wrote: > >> >>> >>> As I mentioned earlier, I don't think `closed` is a good keyword standing >>> alone. And I also think that, given that we have `open`, `closed` also >>> won't pair well with `public`—they sound like antonyms

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

of resilient enums, not closed enums. > >> On Feb 8, 2017, at 3:05 PM, Matthew Johnson via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> This proposal introduces the new access modifier `closed` as well as >> clarifying the meaning of `public`

Re: [swift-evolution] Simplifying Default Access Modifiers

Sent from my iPad > On Feb 13, 2017, at 3:02 AM, Jonathan Hull via swift-evolution > wrote: > > I would like to propose a change to the default access modifier within an > enclosing scope. The default for top level definitions would stay internal, > but anything

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

Sent from my iPad > On Feb 13, 2017, at 1:35 AM, Rien via swift-evolution > wrote: > > >> On 13 Feb 2017, at 06:16, Derrick Ho via swift-evolution >> wrote: >> >> I think I we can live with the original three: public, internal, and

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

> On Feb 12, 2017, at 3:52 PM, Xiaodi Wu wrote: > > On Sun, Feb 12, 2017 at 3:47 PM, Matthew Johnson > wrote: > >> On Feb 12, 2017, at 3:45 PM, Xiaodi Wu > > wrote:

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

> On Feb 12, 2017, at 3:45 PM, Xiaodi Wu wrote: > > On Sun, Feb 12, 2017 at 3:24 PM, Matthew Johnson > wrote: > >> On Feb 12, 2017, at 2:35 PM, Xiaodi Wu via swift-evolution >>

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

> On Feb 12, 2017, at 2:35 PM, Xiaodi Wu via swift-evolution > wrote: > > _Potentially_ meaningful, certainly. But what I'm hearing is that it isn't > actually meaningful. Here's why: > > If I see `fileprivate` and can understand that to mean "gee, the author >

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

was also an important consideration that I believe applies here. > > Nevin > > > On Sunday, February 12, 2017, Matthew Johnson via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > >> On Feb 12, 2017, at 10:24 AM, David

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

> On Feb 12, 2017, at 10:34 AM, Charlie Monroe via swift-evolution > wrote: > > >> On Feb 12, 2017, at 5:19 PM, David Hart via swift-evolution >> > wrote: >> >> I was reading this nice listing of Swift

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

osal aims to do is to incorporate it into a >> consistent system of outside-the-module access modifiers. >> >> One can make a very reasonable argument that access modifiers should *only* >> be in the business of talking about visibility and should stay out of the >&g

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

> On Feb 12, 2017, at 10:19 AM, David Hart via swift-evolution > wrote: > > I was reading this nice listing of Swift keywords > (https://medium.com/the-traveled-ios-developers-guide/swift-keywords-v-3-0-1-f59783bf26c#.2s2yis3zh > >

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

can add to the set of cases / subclasses / conformances”. The time for that argument was when we had the `open` discussion last year. I happen to like the direction we went because it places `public` and `open` on equal footing. And now that we *have* decided to go in this direction, I think w

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

> On Feb 11, 2017, at 4:41 PM, Karl Wagner <razie...@gmail.com> wrote: > > >> On 11 Feb 2017, at 20:50, Matthew Johnson via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >>> >>&g

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

7, at 9:48 PM, Xiaodi Wu <xiaodi...@gmail.com > <mailto:xiaodi...@gmail.com>> wrote: > >> On Wed, Feb 8, 2017 at 5:05 PM, Matthew Johnson via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> I’ve been thinking a lot abo

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

> On Feb 11, 2017, at 7:56 AM, Karl Wagner <razie...@gmail.com> wrote: > > >> On 11 Feb 2017, at 14:37, Karl Wagner <karl.sw...@springsup.com >> <mailto:karl.sw...@springsup.com>> wrote: >> >> >>> On 9 Feb 2017, at 00:05, Matthew

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

> On Feb 11, 2017, at 7:37 AM, Karl Wagner <razie...@gmail.com> wrote: > > >> On 9 Feb 2017, at 00:05, Matthew Johnson via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> I’ve been thinking

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

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

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

to sub-type (currently only classes are supported). >>>>>> The client is allowed to conform to open protocols >>>>>> The client is allowed to override open type members >>>>>> This also means that extensibility is still allowed to public types. &g

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

`abstract final class`. > > Regards, > Rien > > Site: http://balancingrock.nl > Blog: http://swiftrien.blogspot.com > Github: http://github.com/Balancingrock > Project: http://swiftfire.nl > > > > > >> On 11 Feb 2017, at 14:07, Matthew Johnson via swift-ev

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

ll leave us the possibility to think of sub-typing enums in the >>>>> future (I sketched it out a little above). >>>>> >>>> Value subtyping is very interesting. I have been working on some ideas >>>> around this but I want to keep this thread focused

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

ad something like this: > > @closed enum X { > case x, y > func foo() { > switch self { > case .x, .y: > print("swift") > } > } > > enum Z : X { > case z, zz > override func foo() { > // Iff `self

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

Sent from my iPad > On Feb 10, 2017, at 9:48 PM, Xiaodi Wu <xiaodi...@gmail.com> 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 modi

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

for `closed`). > > I dislike intensely the contortions I had to go through to justify `open` as > a spelling, and I'd be a little sad to see such reasoning propagate further. > But at the end of the day, I think if we go in with eyes open and explicitly > accept or reject a no

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 >

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:

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

sure we should bother displaying it in generated > interfaces (although the compiler should still be able to take advantage of > it in clients). `final` can be pretty useful when reasoning about code. It’s more than just a performance optimization. It also represents a compiler proof abo

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

> On Feb 10, 2017, at 10:55 AM, Tino Heth via swift-evolution > wrote: > >>> I'm not sure if I like the concept of having two kinds of enum. >> >> Why not? Bool-like enums would be declared ‘closed’, and would not require a >> default case (but adding a new case

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

tract for enums than they do for classes and protocols. In > fact, `open` for enums would have a contract analagous with `public` for > classes and protocols. This feels like a recipe for confusion. IMO, having > consistent semantics for each keyword is pretty important. We already have,

Re: [swift-evolution] Class and Subclass Existentials (Round 2)

> On Feb 9, 2017, at 2:44 PM, David Hart <da...@hartbit.com> wrote: > > > On 9 Feb 2017, at 20:43, Matthew Johnson via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > >> >> >> Sent from my i

Re: [swift-evolution] Class and Subclass Existentials (Round 2)

Sent from my iPad > On Feb 9, 2017, at 1:30 PM, Hooman Mehr via swift-evolution > wrote: > > >>> On Feb 9, 2017, at 10:47 AM, Joe Groff via swift-evolution >>> wrote: >>> On Feb 9, 2017, at 4:26 AM, Step Christopher via swift-evolution

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

> On Feb 9, 2017, at 11:16 AM, Jens Alfke via swift-users > wrote: > > >> On Feb 9, 2017, at 3:41 AM, Jan Neumüller via swift-users >> > wrote: >> >> I would prefer http://www.fudforum.org/

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

t; // v1: > case javaScript(String) > case javaScript(String, scope: Document) > > // or v2: > case javaScript(String, scope: Document? = nil) > > > > -- > Adrian Zubarev > Sent with Airmail > > Am 9. Februar 2017 um 16:57:40, Matthew Johnson vi

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

e better served by annotations and proper semantic versioning. >> >> As this change didn't seem in scope for Swift 4 phase 1, I've held off on >> discussing my own thoughts on access levels. The idea I was going to propose >> in phase 2 was to have simply open and public

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

ntracts. If we want keywords with consistent semantics we are going to have to introduce a new keyword for the third meaning. > On Wed, Feb 8, 2017 at 17:05 Matthew Johnson via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > I’ve

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

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 have identified what I think is a promising direction and am interested in

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

> On Feb 7, 2017, at 3:01 PM, Michael Ilseman via swift-evolution > wrote: > > BTW, this will likely be part of the eventual design of “open”/resilient > enums ala > https://github.com/apple/swift/blob/master/docs/LibraryEvolution.rst#enums >

Re: [swift-evolution] [RFC][Proposal] Ease restrictions on protocol nesting

> On Feb 6, 2017, at 11:12 PM, Karl Wagner via swift-evolution > wrote: > > >> On 7 Feb 2017, at 06:05, Slava Pestov > > wrote: >> >>> >>> On Feb 6, 2017, at 9:00 PM, Karl Wagner via swift-evolution >>>

Re: [swift-evolution] [swift-build-dev] Package manager support for versioning (both language and tools)

> On Feb 6, 2017, at 2:06 PM, Rick Ballard wrote: > > Hi Matthew, > > The reason I was suggesting a simple DSL in a comment instead of using Swift > for that declaration is because we need to know what this value is before we > start the Swift interpreter, so that we know

Re: [swift-evolution] Class and Subclass Existentials (Round 2)

This looks really good, thank you for your work on this proposal David! I agree with Doug’s suggestion to pick #4 (typealias AnyObject = class) and move the other options to alternatives considered. This seems like the best way to go given Swift’s source compatibility promise and will

Re: [swift-evolution] Subclass Existentials

> On Feb 6, 2017, at 11:30 AM, Douglas Gregor via swift-evolution > wrote: > > >> On Feb 5, 2017, at 3:20 PM, David Hart > > wrote: >> >> As they are heavily linked, should a change like this be included in the >>

Re: [swift-evolution] [swift-build-dev] Package manager support for versioning (both language and tools)

It’s clear that a lot of work has gone into identifying and evaluating several different approaches. Thank you for doing the hard work here! I think I might have one additional alternative to consider. I like the idea of using Package.swift to specify the tools version, but I think the

Re: [swift-evolution] Removing enumerated?

> On Feb 3, 2017, at 3:41 PM, Ben Cohen via swift-evolution > wrote: > > >> On Feb 2, 2017, at 8:46 PM, Chris Lattner > > wrote: >> >> It seems that you are leaning towards removing enumerated(). > > I’m actually

Re: [swift-evolution] Either protocol syntax

> On Feb 2, 2017, at 4:02 PM, Rex Fenley wrote: > > But then any time as user of the pipeline I'm writing would like a new type > of collection they will be forced to inherit this new protocol vs one they're > already familiar with and which the collection may already

Re: [swift-evolution] Either protocol syntax

> > On Feb 2, 2017, at 3:26 PM, Rex Fenley via swift-evolution > wrote: > > Hello, I believe there was some discussion about this quite awhile ago. I was > wondering if there's any interest in including a protocol 'or' type that > would be the intersection of two

Re: [swift-evolution] Strings in Swift 4

> On Feb 2, 2017, at 1:19 PM, Dave Abrahams via swift-evolution > wrote: > > > on Thu Feb 02 2017, Matthew Johnson wrote: > >>> On Feb 2, 2017, at 9:45 AM, Dave Abrahams >> wrote: >>> >>> >>> >>> >> >>> >>> On

Re: [swift-evolution] Strings in Swift 4

> On Feb 2, 2017, at 9:45 AM, Dave Abrahams wrote: > > > > Sent from my iPad > > On Feb 2, 2017, at 7:11 AM, Matthew Johnson > wrote: > >>> Furthermore, we emphatically do *not* need to make the

Re: [swift-evolution] Strings in Swift 4

> On Feb 2, 2017, at 6:07 AM, Brent Royal-Gordon via swift-evolution > wrote: > >> On Feb 2, 2017, at 3:06 AM, Jaden Geller via swift-evolution >> wrote: >> >> It's not infinite (else subscript would trap) > > I'm not necessarily a fan

Re: [swift-evolution] Strings in Swift 4

> On Feb 1, 2017, at 9:52 AM, Nevin Brackett-Rozinsky > wrote: > > Drafting a proposal sounds like a good idea, to establish all the relevant > information in one place. I don’t recall off the top of my head what > directions Jaden sketched out, but as long

Re: [swift-evolution] Strings in Swift 4

> On Feb 1, 2017, at 9:15 AM, Nevin Brackett-Rozinsky > <nevin.brackettrozin...@gmail.com> wrote: > > I am also +1. > > > On Wed, Feb 1, 2017 at 9:29 AM, Matthew Johnson via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org

Re: [swift-evolution] Strings in Swift 4

> On Feb 1, 2017, at 6:58 AM, Brent Royal-Gordon via swift-evolution > wrote: > >> On Jan 31, 2017, at 2:04 PM, Xiaodi Wu via swift-evolution >> wrote: >> >> Therefore I'd conclude that `arr[upTo: i]` is the most consistent spelling. >>

Re: [swift-evolution] Strings in Swift 4

Sent from my iPad > On Jan 31, 2017, at 7:28 PM, Xiaodi Wu wrote: > >> On Tue, Jan 31, 2017 at 7:08 PM, Matthew Johnson >> wrote: >> >>> On Jan 31, 2017, at 6:54 PM, Xiaodi Wu wrote: >>> On Tue, Jan 31, 2017 at 6:40

Re: [swift-evolution] Strings in Swift 4

> On Jan 31, 2017, at 6:54 PM, Xiaodi Wu wrote: > > On Tue, Jan 31, 2017 at 6:40 PM, Matthew Johnson > wrote: > >> On Jan 31, 2017, at 6:15 PM, Xiaodi Wu > > wrote:

Re: [swift-evolution] Strings in Swift 4

> On Jan 31, 2017, at 6:15 PM, Jaden Geller <jaden.gel...@gmail.com> wrote: > > >> On Jan 31, 2017, at 4:09 PM, Matthew Johnson via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> >>>

Re: [swift-evolution] Strings in Swift 4

> On Jan 31, 2017, at 6:15 PM, Xiaodi Wu wrote: > > On Tue, Jan 31, 2017 at 6:09 PM, Matthew Johnson > wrote: > >> On Jan 31, 2017, at 5:35 PM, Xiaodi Wu via swift-evolution >>

Re: [swift-evolution] Strings in Swift 4

> On Jan 31, 2017, at 5:35 PM, Xiaodi Wu via swift-evolution > wrote: > > On Tue, Jan 31, 2017 at 5:28 PM, David Sweeris > wrote: > >> On Jan 31, 2017, at 2:04 PM, Xiaodi Wu >

Re: [swift-evolution] Strings in Swift 4

> On Jan 31, 2017, at 5:20 PM, Xiaodi Wu wrote: > > On Tue, Jan 31, 2017 at 5:04 PM, Matthew Johnson > wrote: > > I think it’s fair to say that we get to decide on the semantics of postfix > `…`. “a range with no

Re: [swift-evolution] Strings in Swift 4

> On Jan 31, 2017, at 4:04 PM, Xiaodi Wu via swift-evolution > wrote: > > On Tue, Jan 31, 2017 at 3:36 PM, David Sweeris via swift-evolution > > wrote: > > On Jan 31, 2017, at 11:32, Jaden Geller via

Re: [swift-evolution] Removing enumerated?

> On Jan 31, 2017, at 2:46 PM, Ben Cohen wrote: > >> >> On Jan 31, 2017, at 12:18 PM, Matthew Johnson > > wrote: >> >>> >>> On Jan 31, 2017, at 1:16 PM, Ben Cohen via swift-evolution >>>

Re: [swift-evolution] Removing enumerated?

> On Jan 31, 2017, at 1:16 PM, Ben Cohen via swift-evolution > wrote: > > I think whether enumerated() is justified as a method on Sequence is one > example of a wider question which definitely needs some discussion, which is: > where should the standard library

Re: [swift-evolution] Removing enumerated?

an experienced programmer who is new to the language to bump up against this when the reach for `enumerated`. They’re going to need to learn the collection model sooner or later. > > On Tue, 31 Jan 2017 at 17:41, Matthew Johnson via swift-evolution > <swift-evolution@swift.org

Re: [swift-evolution] Removing enumerated?

> On Jan 31, 2017, at 10:36 AM, Xiaodi Wu via swift-evolution > wrote: > > I totally sympathize with users being confused. It's an interesting idea to > move it to Array only. > > The thing is, it does make sense (and wouldn't be confusing) to enumerate a >

Re: [swift-evolution] Warn about unused Optional.some(())

Sent from my iPad > On Jan 30, 2017, at 5:25 PM, Slava Pestov via swift-evolution > wrote: > > >> On Jan 30, 2017, at 2:58 PM, Daniel Duan via swift-evolution >> wrote: >> >> Hi all, >> >> Right now, expressions that evaluates to

Re: [swift-evolution] Public struct init is unexpectedly internal

> On Jan 30, 2017, at 3:32 AM, Slava Pestov via swift-evolution > wrote: > > >> On Jan 30, 2017, at 1:30 AM, David Sweeris > > wrote: >> >> >>> On Jan 30, 2017, at 1:21 AM, Slava Pestov >>

Re: [swift-evolution] Subclass Existentials

> On Jan 29, 2017, at 10:47 PM, Slava Pestov <spes...@apple.com> wrote: > > >> On Jan 29, 2017, at 2:05 PM, Matthew Johnson via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >>> >>&

Re: [swift-evolution] Subclass Existentials

> On Jan 29, 2017, at 4:48 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote: > > On Sun, Jan 29, 2017 at 4:19 PM, Matthew Johnson via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > >> On Jan 29, 2017, at 4:01 PM, David

Re: [swift-evolution] Subclass Existentials

> On Jan 29, 2017, at 4:01 PM, David Hart wrote: > > Hi Matthew, > > I’ll reply to this post, because it allows me to discuss a few of the points > in the discussion, but I’ve read the whole discussion. > >> On 29 Jan 2017, at 18:30, Matthew Johnson

Re: [swift-evolution] Subclass Existentials

> On Jan 29, 2017, at 3:52 PM, Xiaodi Wu wrote: > > On Sun, Jan 29, 2017 at 3:35 PM, Matthew Johnson > wrote: > >> On Jan 29, 2017, at 3:24 PM, Xiaodi Wu > > wrote:

Re: [swift-evolution] Subclass Existentials

> On Jan 29, 2017, at 3:24 PM, Xiaodi Wu wrote: > > On Sun, Jan 29, 2017 at 3:11 PM, Matthew Johnson > wrote: > >> On Jan 29, 2017, at 3:05 PM, Xiaodi Wu > > wrote:

Re: [swift-evolution] Subclass Existentials

> On Jan 29, 2017, at 3:05 PM, Xiaodi Wu wrote: > > On Sun, Jan 29, 2017 at 2:40 PM, Matthew Johnson > wrote: > >> On Jan 29, 2017, at 2:25 PM, Xiaodi Wu > > wrote:

Re: [swift-evolution] Subclass Existentials

> On Jan 29, 2017, at 2:25 PM, Xiaodi Wu wrote: > > On Sun, Jan 29, 2017 at 2:16 PM, Matthew Johnson > wrote: > >> On Jan 29, 2017, at 2:01 PM, Xiaodi Wu > > wrote:

Re: [swift-evolution] Subclass Existentials

> On Jan 29, 2017, at 2:01 PM, Xiaodi Wu wrote: > > On Sun, Jan 29, 2017 at 1:37 PM, Matthew Johnson > wrote: > > > Sent from my iPad > > On Jan 29, 2017, at 12:58 PM, Xiaodi Wu via swift-evolution >

Re: [swift-evolution] Subclass Existentials

Sent from my iPad > On Jan 29, 2017, at 12:58 PM, Xiaodi Wu via swift-evolution > wrote: > > Cool. Another avenue of improvement here is relaxing the single-class > spelling rule for the sake of composing typealiases. > > As Matthew mentioned, if I have class

Re: [swift-evolution] Subclass Existentials

Hi David, This looks like a great start. One thing we should consider is whether we tie this proposal so tightly to classes or whether it might be better to call these supertype constraints. The feature might also be useful for value types if / when Swift gets value subtyping. One

Re: [swift-evolution] Strings in Swift 4

> > Right. The standard approach we take in Swift has been to start with > something baked into the language, then generalize it out to the stdlib over > time if there is a reason to. I’d love to see the various magic around > Optional be accessible to other types, for example. > > -Chris

Re: [swift-evolution] A case for postponing ABI stability

> On Jan 26, 2017, at 9:48 PM, Dave Abrahams via swift-evolution > wrote: > > > on Thu Jan 26 2017, Matthew Johnson wrote: > >>> On Jan 26, 2017, at 3:10 PM, Dave Abrahams via swift-evolution >>> wrote: >>>

Re: [swift-evolution] A case for postponing ABI stability

> On Jan 26, 2017, at 8:22 PM, Michael Ilseman <milse...@apple.com> wrote: > > >> On Jan 26, 2017, at 5:48 PM, Matthew Johnson via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> >> >

Re: [swift-evolution] A case for postponing ABI stability

Sent from my iPad > On Jan 26, 2017, at 7:29 PM, Ted Kremenek <kreme...@apple.com> wrote: > > >> On Jan 26, 2017, at 12:19 PM, Matthew Johnson via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> Locking down ABI when all fore

Re: [swift-evolution] A case for postponing ABI stability

> On Jan 26, 2017, at 3:10 PM, Dave Abrahams via swift-evolution > wrote: > > > on Thu Jan 26 2017, David Hart wrote: > >> Thanks Michael for the manifesto. It definitely made quite a few things >> clearer for me. >> >> Concerning the

Re: [swift-evolution] A case for postponing ABI stability

> On Jan 26, 2017, at 2:12 PM, David Hart via swift-evolution > wrote: > > Thanks Michael for the manifesto. It definitely made quite a few things > clearer for me. > > Concerning the topic of when ABI stability should happen, I still have a > strong feelings that

Re: [swift-evolution] [Discussion] mailing list alternative

> On Jan 26, 2017, at 1:44 PM, Dave Abrahams via swift-evolution > wrote: > > > on Thu Jan 26 2017, Matthew Johnson wrote: > >>> On Jan 26, 2017, at 12:26 PM, Daniel Duan via swift-evolution >>> wrote: >>>

Re: [swift-evolution] Strings in Swift 4

> On Jan 26, 2017, at 1:15 PM, Dave Abrahams via swift-evolution > wrote: > > > on Wed Jan 25 2017, Chris Lattner wrote: > >> On Jan 25, 2017, at 7:32 PM, Dave Abrahams wrote: There are two important use cases for regex's: the literal

Re: [swift-evolution] [Discussion] mailing list alternative

Sent from my iPad > On Jan 26, 2017, at 12:26 PM, Daniel Duan via swift-evolution > wrote: > > I'm actually convinced that I'd rather use an email client. Having to > participate in a web app is a regression in my experience. +1. I like email way better than web

Re: [swift-evolution] Strings in Swift 4

> On Jan 25, 2017, at 12:23 PM, Joe Groff via swift-evolution > wrote: > > >> On Jan 24, 2017, at 9:35 PM, Chris Lattner via swift-evolution >> > wrote: >> >> On Jan 24, 2017, at 12:05 AM, Chris Eidhof

Re: [swift-evolution] Strings in Swift 4

> On Jan 24, 2017, at 10:14 AM, Chris Eidhof wrote: > > Hey Matthew, > > Do you have an example of doing parser combinators without FP? I'd be very > interest Hey Chris, looks like Dave provided a pretty good example of the kind of thing I was talking about. Does that

Re: [swift-evolution] [draft] Compound Names For Enum Cases

> On Jan 24, 2017, at 3:10 PM, Christopher Kornher via swift-evolution > wrote: > > Your example is only has only one case, which is not typical. Perhaps I am > missing something, but the only reason that I can imagine for having a case > with multiple ways to

Re: [swift-evolution] Reduce with inout

say that you > reduce “into” the seed value. > > Labeling the argument `into` is a little bit of a stretch but I think it's > far superior to `mutating` which is pretty misleading at the call site. I > think it would be pretty hard to come up with something better, but let’s >

Re: [swift-evolution] Reduce with inout

if anyone has additional ideas. > On Tue, Jan 24, 2017 at 12:44 Matthew Johnson via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> On Jan 24, 2017, at 12:36 PM, Pyry Jahkola via swift-evolution >> <swift-evolution@swift

Re: [swift-evolution] Reduce with inout

> On Jan 24, 2017, at 12:36 PM, Pyry Jahkola via swift-evolution > wrote: > > > Freak Show wrote: > >> Am I the only one who finds this incredibly ugly and hard to read? >> >> This is more or less solved by inject:into: idiom. There is no reason for >> inout for

Re: [swift-evolution] Strings in Swift 4

> On Jan 24, 2017, at 2:05 AM, Chris Eidhof via swift-evolution > wrote: > > I agree that being able to implement parsers in a nice way can be a huge step > forward in being really good at string processing. > > There are a couple of possibilities that come to mind

Re: [swift-evolution] Reduce with inout

is less a concern with less common and less frequently used signatures. > > On Tue, Jan 24, 2017 at 07:33 Matthew Johnson via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > > > Sent from my iPad > > On Jan 24, 2017, at

Re: [swift-evolution] Reduce with inout

Sent from my iPad > On Jan 24, 2017, at 1:54 AM, Chris Eidhof via swift-evolution > wrote: > > I've thought about it for a few days, and really like `reduce(mutating:_)`. I'm not a fan of this. It reads in a way that makes it seem like the parameter should be

Re: [swift-evolution] [draft] Compound Names For Enum Cases

Sent from my iPad > On Jan 23, 2017, at 8:48 PM, Karl Wagner wrote: > > >>> On 24 Jan 2017, at 01:03, Joe Groff via swift-evolution >>> wrote: >>> >>> On Jan 23, 2017, at 4:00 PM, Matthew Johnson wrote:

Re: [swift-evolution] Default Generic Arguments

This proposal looks good to me. I have been looking forward to more flexible generic arguments for a while. I agree with previous commenters who prefer the option to leave off the angle brackets when all parameters have defaults. The proposal specifically mentions that the syntax is inspired

Re: [swift-evolution] [draft] Compound Names For Enum Cases

> On Jan 23, 2017, at 6:03 PM, Joe Groff wrote: > > >> On Jan 23, 2017, at 4:00 PM, Matthew Johnson > > wrote: >> >> >>> On Jan 23, 2017, at 5:52 PM, Joe Groff >> > wrote:

Re: [swift-evolution] [draft] Compound Names For Enum Cases

> On Jan 23, 2017, at 5:52 PM, Joe Groff wrote: > >> >> On Jan 23, 2017, at 3:49 PM, Matthew Johnson > > wrote: >> >> >> >> Sent from my iPad >> >> On Jan 23, 2017, at 3:32 PM, Joe Groff via swift-evolution >>

Re: [swift-evolution] Strings in Swift 4

> On Jan 23, 2017, at 4:27 PM, Joe Groff via swift-evolution > wrote: > > >> On Jan 23, 2017, at 2:06 PM, Ben Cohen via swift-evolution >> > wrote: >> >> >>> On Jan 23, 2017, at 7:49 AM, Joshua Alvarado

Re: [swift-evolution] [draft] Compound Names For Enum Cases

Sent from my iPad > On Jan 23, 2017, at 3:32 PM, Joe Groff via swift-evolution > wrote: > > This looks pretty good! It might be worth calling out explicitly that > matching a payloaded case by name alone still works, e.g.: > > enum Foo { case foo(Int), bar(x:

Re: [swift-evolution] [draft] Compound Names For Enum Cases

> On Jan 22, 2017, at 3:51 AM, Robert Widmann via swift-evolution > wrote: > > Sure. One of the first gadgets I wrote was a way of destructuring an array > into a familiar cons-list kind of enum > (https://github.com/typelift/Basis/blob/master/Basis/Array.swift#L9

Re: [swift-evolution] Strings in Swift 4

This looks really great to me. I am not an expert in this area so I don’t have a lot of detailed comments. That said, it looks like it will significantly improve the string handling experience of app developers, including better bridging to the APIs we work with every day. I did notice one

<    1   2   3   4   5   6   7   8   9   10   >