Re: [swift-evolution] [Proposal Draft] Literal Syntax Protocols

> On Jun 29, 2016, at 5:04 PM, Brent Royal-Gordon <br...@architechies.com> > wrote: > >> On Jun 29, 2016, at 7:41 AM, Matthew Johnson via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> `Syntax.IntegerLiteralType` is another that p

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

> On Jun 29, 2016, at 4:12 PM, Xiaodi Wu via swift-evolution > wrote: > > On Wed, Jun 29, 2016 at 4:07 PM, Jordan Rose > wrote: > >> On Jun 29, 2016, at 14:03, Xiaodi Wu >

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

> On Jun 29, 2016, at 5:33 PM, Michael Peternell via swift-evolution > wrote: > > >> Am 30.06.2016 um 00:17 schrieb Xiaodi Wu via swift-evolution >> : >> >> Here is the problem: >> >> ``` >> private struct Foo { >> /* private */ struct

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

> On Jun 29, 2016, at 5:44 PM, Xiaodi Wu wrote: > > On Wed, Jun 29, 2016 at 5:41 PM, Matthew Johnson > wrote: > >> On Jun 29, 2016, at 5:30 PM, Xiaodi Wu > > wrote:

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

> On Jun 29, 2016, at 6:04 PM, Xiaodi Wu wrote: > > > > On Wed, Jun 29, 2016 at 6:00 PM, Matthew Johnson > wrote: > >> On Jun 29, 2016, at 5:44 PM, Xiaodi Wu > >

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

> On Jun 29, 2016, at 6:05 PM, David Sweeris via swift-evolution > wrote: > > > > Sent from my iPhone > >> On Jun 29, 2016, at 17:45, Rod Brown via swift-evolution >> wrote: >> >> From my understanding, "Sealed" or whatever we will

Re: [swift-evolution] [Proposal Draft] Literal Syntax Protocols

> On Jul 1, 2016, at 11:00 AM, Erica Sadun wrote: > > The best way to pass the Dave Test is to ask him directly, for example: > > Dave: > > Do you think the stdlib team would be okay with a naming scheme like > Syntax.Literal.ArrayProtocol,

Re: [swift-evolution] [Pitch] Remove destructive consumption from Sequence

> On Jun 30, 2016, at 12:26 PM, Dave Abrahams <dabrah...@apple.com> wrote: > > > on Wed Jun 29 2016, Haravikk wrote: > >>> On 29 Jun 2016, at 00:10, Matthew Johnson via swift-evolution >>> <swift-evolution@swift.org> wrote: >>> >&g

Re: [swift-evolution] [Pitch] Remove destructive consumption from Sequence

> On Jun 30, 2016, at 5:39 PM, Dave Abrahams wrote: > > > on Thu Jun 30 2016, Haravikk wrote: > >>> On 30 Jun 2016, at 18:26, Dave Abrahams wrote: >>> >>> Q: Why should there be indices on an infinite multipass sequence? >>> A: Because the

Re: [swift-evolution] [Pitch] Remove destructive consumption from Sequence

e on what designs / data structures you’re talking about here? > >> On Thu, Jun 30, 2016 at 12:26 Dave Abrahams via swift-evolution < >> swift-evolution@swift.org> wrote: >> >>> >>> on Wed Jun 29 2016, Haravikk wrote: >>> >>>>&

Re: [swift-evolution] [Pitch] Remove destructive consumption from Sequence

> On Jul 1, 2016, at 9:47 AM, Dave Abrahams wrote: > > > on Fri Jul 01 2016, Haravikk wrote: > >>> On 30 Jun 2016, at 23:39, Dave Abrahams wrote: >>> All multi-pass sequences can benefit from subscripts. >> >> Sorry, not really what I meant, but

Re: [swift-evolution] [Pitch] Remove destructive consumption from Sequence

gt;>>> >>>> >>>>>>> On Jun 30, 2016, at 12:26 PM, Dave Abrahams <dabrah...@apple.com >>>>>>> <mailto:dabrah...@apple.com>> >>>>>> wrote: >>>>>>> >>>>>>> >>>>

Re: [swift-evolution] [Review] SE-0115: Rename Literal Syntax Protocols

Sent from my iPad > On Jul 2, 2016, at 6:11 AM, Anton Zhilin via swift-evolution > wrote: > > -1 from me. I suggest to wait until we get generic protocols > in Swift 4, then we can use the following: > > protocol From { >init(_ from: T) > } This is extremely

Re: [swift-evolution] [Review] SE-0115: Rename Literal Syntax Protocols

Sent from my iPad On Jul 2, 2016, at 9:10 AM, Anton Zhilin via swift-evolution wrote: >>> Anton Zhilin via swift-evolution writes: >>> -1 from me. I suggest to wait until we get generic protocols >>> in Swift 4, then we can use the following:

Re: [swift-evolution] Take 2: Stdlib closure argument labels and parameter names

Sent from my iPad > On Jul 1, 2016, at 7:03 PM, Dave Abrahams via swift-evolution > wrote: > > >> on Wed Jun 29 2016, Matthew Johnson wrote: >> >> Sent from my iPad >> >>> On Jun 29, 2016, at 1:39 AM, Dave Abrahams via swift-evolution

Re: [swift-evolution] [Pitch] Importing Objective-C 'id' as Swift 'Any'

I'm really happy to see this. It cleans things up and enables some really important things such as more idiomatic bridging (NSNumber to native numeric types is amazing!). The ideas mentioned will really help to make Cocoa feel as Swifty as possible. Sent from my iPad > On Jul 1, 2016, at

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0114: Updating Buffer "Value" Names to "Header" Names

> > * What is your evaluation of the proposal? +1. Echoing what others have already said, this is a much better name. > * Is the problem being addressed significant enough to warrant a change > to Swift? Yes. > * Does this proposal fit well with the feel and direction

Re: [swift-evolution] [Proposal] Union Type

Sent from my iPad > On Jul 1, 2016, at 1:59 PM, David Sweeris via swift-evolution > wrote: > > It’s already on that list. That’s what Joe was quoting from earlier. > > Everybody (I hope) understands the “something the type system cannot […] > support” part, but

Re: [swift-evolution] [Proposal Draft] Literal Syntax Protocols

> On Jul 1, 2016, at 3:59 PM, Dmitri Gribenko via swift-evolution > wrote: > > On Fri, Jul 1, 2016 at 1:35 PM, Dave Abrahams via swift-evolution > wrote: >> I think if `Syntax.IntegerLiteral` is actually unclear then the best >> cure is

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

There is nothing preventing you from using fileprivate if you want to write your code in this style. At most you can complain that you don't like the new keyword. But you're not losing any functionality so I don't understand why you say you are "missing" something. Sent from my iPad > On

Re: [swift-evolution] [Proposal Draft] Literal Syntax Protocols

> On Jun 29, 2016, at 9:15 AM, Erica Sadun via swift-evolution > wrote: > > I rather like this one. It produces: `Syntax.Literal.IntegerProtocol`, which > is honestly > the best I've seen so far *and* it might get past the Dave test. I’m curious to see what Dave

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0107: UnsafeRawPointer API

> > * What is your evaluation of the proposal? +1. This proposal looks really great to me. I think it will add a lot of clarity to code that needs to work with unsafe pointers. This is really important. > * Is the problem being addressed significant enough to warrant a change

Re: [swift-evolution] [Proposal Draft] Literal Syntax Protocols

> On Jun 29, 2016, at 9:46 AM, Adrian Zubarev via swift-evolution > wrote: > > I wouldn’t use the Type suffix, because I believe this will create even more > confusion with the associatedtype IntegerLiteralType from the current > IntegerLiteralConvertible itself. >

Re: [swift-evolution] Take 2: Stdlib closure argument labels and parameter names

> On Jun 29, 2016, at 10:13 AM, Erica Sadun via swift-evolution > wrote: > > >> On Jun 29, 2016, at 12:39 AM, Dave Abrahams via swift-evolution >> wrote: >> >> >> I've updated my pull request with a much more conservative set of >>

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

> On Jun 29, 2016, at 10:46 AM, Sean Heber <s...@fifthace.com> wrote: > >> >> On Jun 29, 2016, at 10:22 AM, Matthew Johnson via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> >>> On Jun 29, 2016, at 10:08 AM, David H

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

@gmail.com >> <mailto:xiaodi...@gmail.com>> wrote: >> >> On Wed, Jun 29, 2016 at 10:52 AM, Matthew Johnson via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>>wrote: >> >>> On Jun 29, 2016, at 10:46 AM, Sean H

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

e found a way to improve the naming a new proposal can be put forward. If an obviously better name is suggested I will support such a proposal enthusiastically! > > Austin > > On Wed, Jun 29, 2016 at 9:10 AM, Matthew Johnson via swift-evolution > <swift-evolution@swift.or

Re: [swift-evolution] [Proposal] Add floor() and ceiling() functions to FloatingPoint

+1 to adding robust rounding to he standard library. I’m curious why we have both `up` and `down`, but only have `towardZero` without `awayFromZero`. I’m also curious what the use case is for `toNearestOrEven` and why you don’t include `toNearestOrOdd`. I think the name of

Re: [swift-evolution] [Proposal] Add floor() and ceiling() functions to FloatingPoint

Sent from my iPhone > On Jun 29, 2016, at 12:00 PM, Stephen Canon wrote: > > >> On Jun 29, 2016, at 12:46 PM, Matthew Johnson wrote: >> >> +1 to adding robust rounding to he standard library. >> >> I’m curious why we have both `up` and `down`, but

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

Sent from my iPhone > On Jun 29, 2016, at 12:15 PM, Michael Peternell via swift-evolution > wrote: > > >> Am 29.06.2016 um 15:54 schrieb David Sweeris via swift-evolution >> : >> >> +1 for the concept of a "sealed” class. >> -1 for

Re: [swift-evolution] [Pitch] Remove destructive consumption from Sequence

: >>> >>> >>> on Wed Jun 29 2016, Haravikk wrote: >>> >> >>>>> On 29 Jun 2016, at 00:10, Matthew Johnson via swift-evolution >>>>> <swift-evolution@swift.org> wrote: >>>>> >>>>> Swift i

Re: [swift-evolution] [Pitch] Remove destructive consumption from Sequence

>> >> >>>>> On Jun 30, 2016, at 12:26 PM, Dave Abrahams <dabrah...@apple.com >>>>> <mailto:dabrah...@apple.com>> >>>> wrote: >>>>> >>>>> >>>>> on Wed Jun 29 2016, Haravikk >>>> <http://s

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

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

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

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

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

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

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

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] 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] [Pitch] consistent public access modifiers (value subtyping digression)

Sent from my iPad > On Feb 15, 2017, at 8:17 PM, Jordan Rose <jordan_r...@apple.com> wrote: > > >>> On Feb 13, 2017, at 09:33, Matthew Johnson via swift-evolution >>> <swift-evolution@swift.org> wrote: >>> >>> >>> On Feb 13,

Re: [swift-evolution] [Pitch] consistent public access modifiers (value subtyping digression)

Sent from my iPad > On Feb 15, 2017, at 8:17 PM, Jordan Rose <jordan_r...@apple.com> wrote: > > >>> On Feb 13, 2017, at 09:33, Matthew Johnson via swift-evolution >>> <swift-evolution@swift.org> wrote: >>> >>> >>> On Feb 13,

Re: [swift-evolution] Treating an Enum's Cases as Its Subtypes

t 1:04 PM, Matthew Johnson <matt...@anandabits.com> >>>>>> wrote: >>>>>> >>>>>> >>>>>>> On Feb 20, 2017, at 2:38 PM, Joe Groff <jgr...@apple.com> wrote: >>>>>>> >>>>>>>

Re: [swift-evolution] [Draft] Fix Private Access Levels

Sent from my iPad > On Feb 21, 2017, at 1:47 AM, Rien via swift-evolution > wrote: > > I don’t know if you want to add this to the ‘criticism’ or not. > > 1) The information content added by “fileprivate” is questionable because of > the ‘soft default’: > > -

Re: [swift-evolution] [Draft] Fix Private Access Levels

Sent from my iPhone > On Feb 21, 2017, at 7:51 AM, Vladimir.S via swift-evolution > wrote: > > FWIW, I do think "Solution 2: Rename the scoped access level to scoped" is > the best solution. It has(like current 'private') a value of protecting (even > from

<    3   4   5   6   7   8   9   10   11   12   >