Re: [swift-evolution] [Pitch/plea] Recursive protocol constraints

> On Jan 2, 2017, at 1:03 PM, Dave Abrahams via swift-evolution > wrote: > > > on Mon Jan 02 2017, Austin Zheng > wrote: >> Anyone who wants to help, by the way, is more than welcome to; I'm happy to >> take PRs or just even a

Re: [swift-evolution] Enhanced Existentials

> On Jan 4, 2017, at 21:28, Douglas Gregor wrote: > >> On Jan 4, 2017, at 9:19 PM, David Sweeris wrote: >> >> On Jan 4, 2017, at 20:48, Douglas Gregor via swift-evolution >> wrote: >> >>> Yeah. I'm less sure about the other

Re: [swift-evolution] [Proposal draft] Limiting @objc inference

> On Jan 4, 2017, at 9:36 PM, Charlie Monroe wrote: > > I'm personally coming back and forth on this - my code is now 99% pure Swift, > so I don't really need @objc declarations aside for: > > - CoreData - which is fairly obvious and @NSManaged will scream if the

Re: [swift-evolution] [Thoughts?][Phase2] default arguments and trailing closure syntax

> On Jan 4, 2017, at 9:44 PM, Saagar Jha wrote: > > So, then this should have a warning? I’m still not getting one. > > func foo(a: () -> (), b: (() -> ())? = nil, c: Int) { > a() > b?() > } > > foo(a: { > print(“Bar”) > }, c: 0) > If you give “c” a

Re: [swift-evolution] [Thoughts?][Phase2] default arguments and trailing closure syntax

So, then this should have a warning? I’m still not getting one. func foo(a: () -> (), b: (() -> ())? = nil, c: Int) { a() b?() } foo(a: { print(“Bar”) }, c: 0) Saagar Jha > On Jan 4, 2017, at 9:34 PM, Douglas Gregor wrote: > > >> On Jan 4, 2017,

Re: [swift-evolution] [Proposal draft] Limiting @objc inference

> On Jan 4, 2017, at 8:59 PM, Timothy Wood wrote: > > > > >> On Jan 4, 2017, at 4:50 PM, Douglas Gregor via swift-evolution >> > wrote: > > > >> A Swift 3-to-4 migrator is the hardest part of the story. Ideally,

Re: [swift-evolution] [Proposal draft] Limiting @objc inference

I'm personally coming back and forth on this - my code is now 99% pure Swift, so I don't really need @objc declarations aside for: - CoreData - which is fairly obvious and @NSManaged will scream if the type isn't @objc-compatible - UI - and this is a big part. Unfortunately, I've relied on

Re: [swift-evolution] [Thoughts?][Phase2] default arguments and trailing closure syntax

> On Jan 4, 2017, at 9:32 PM, Saagar Jha wrote: > > > > Saagar Jha > > > >> On Jan 4, 2017, at 8:35 PM, Douglas Gregor > > wrote: >> >> >> On Jan 4, 2017, at 7:48 PM, Saagar Jha via swift-evolution >>

Re: [swift-evolution] [Thoughts?][Phase2] default arguments and trailing closure syntax

Saagar Jha > On Jan 4, 2017, at 8:35 PM, Douglas Gregor wrote: > > > On Jan 4, 2017, at 7:48 PM, Saagar Jha via swift-evolution > > wrote: > >> Check out this thread >>

Re: [swift-evolution] Enhanced Existentials

> On Jan 4, 2017, at 9:19 PM, David Sweeris wrote: > > > On Jan 4, 2017, at 20:48, Douglas Gregor via swift-evolution > > wrote: > >> Yeah. I'm less sure about the other enhancements to existentials fitting >>

Re: [swift-evolution] Enhanced Existentials

> On Jan 4, 2017, at 20:48, Douglas Gregor via swift-evolution > wrote: > > Yeah. I'm less sure about the other enhancements to existentials fitting into > Swift 4, e.g., the creation of existentials for protocols with associated > types. Although important, it's a

Re: [swift-evolution] [Thoughts?][Phase2] default arguments and trailing closure syntax

Sent from my iPhone > On Jan 4, 2017, at 8:40 PM, Derrick Ho wrote: > > So could we add a @trailing or @nontrailing to the block argument to toggle > on and off the feature? But... why? That's a nontrivial amount of complexity for a fairly limited use case. - Doug

Re: [swift-evolution] [Proposal draft] Limiting @objc inference

> On Jan 4, 2017, at 4:50 PM, Douglas Gregor via swift-evolution > wrote: > A Swift 3-to-4 migrator is the hardest part of the story. Ideally, the > migrator to only add @objc in places where it is needed, so that we see some > of the expected benefits of

Re: [swift-evolution] Enhanced Existentials

Sent from my iPhone > On Jan 3, 2017, at 10:08 PM, Rod Brown via swift-evolution > wrote: > >> On 3 Jan 2017, at 11:33 pm, David Hart via swift-evolution >> wrote: >> >> Hello Mailing-list, >> >> I remember we discussed enhanced

Re: [swift-evolution] [Thoughts?][Phase2] default arguments and trailing closure syntax

I think the way it is now works just fine. The only use-case I could see for this would be for having multiple closures, but in that case I think defining them before the function call is clearer anyway. -thislooksfun (tlf) > On Jan 4, 2017, at 10:40 PM, Derrick Ho via swift-evolution >

Re: [swift-evolution] [Thoughts?][Phase2] default arguments and trailing closure syntax

So could we add a @trailing or @nontrailing to the block argument to toggle on and off the feature? On Wed, Jan 4, 2017 at 8:35 PM Douglas Gregor via swift-evolution < swift-evolution@swift.org> wrote: > > On Jan 4, 2017, at 7:48 PM, Saagar Jha via swift-evolution < > swift-evolution@swift.org>

Re: [swift-evolution] [Thoughts?][Phase2] default arguments and trailing closure syntax

> On Jan 4, 2017, at 7:48 PM, Saagar Jha via swift-evolution > wrote: > > Check out this thread–it’s very similar to what you proposed, but it didn’t > go anywhere. FWIW +1 to this as well as the ability to use multiple trailing > closures like so: > >

Re: [swift-evolution] [Thoughts?][Phase2] default arguments and trailing closure syntax

The only difference between your proposed spelling and not using trailing closures at all is the placement of the closing parenthesis, which is not at all a clear enough win sufficient to justify having two spellings for the same thing. I'm of the same opinion that was expressed by Erica Sadun

Re: [swift-evolution] [Proposal draft] Limiting @objc inference

+1. Yeah well thought out and explained. All for consistency and favor being explicit. On Wed, Jan 4, 2017 at 7:01 PM Micah Hainline via swift-evolution < swift-evolution@swift.org> wrote: +1. Well thought out, it's bothered me too. > On Jan 4, 2017, at 7:34 PM, Rick Mann via

Re: [swift-evolution] [Thoughts?][Phase2] default arguments and trailing closure syntax

Check out this thread –it’s very similar to what you proposed, but it didn’t go anywhere. FWIW +1 to this as well as the ability to use multiple trailing closures like so: animate(identifier: “”, duration: 0,

Re: [swift-evolution] [Proposal draft] Limiting @objc inference

+1. Well thought out, it's bothered me too. > On Jan 4, 2017, at 7:34 PM, Rick Mann via swift-evolution > wrote: > > +1 > >> On Jan 4, 2017, at 16:50 , Douglas Gregor via swift-evolution >> wrote: >> >> Hi all, >> >> Here’s a draft

Re: [swift-evolution] [Proposal draft] Limiting @objc inference

+1 > On Jan 4, 2017, at 16:50 , Douglas Gregor via swift-evolution > wrote: > > Hi all, > > Here’s a draft proposal to limit inference of @objc to only those places > where we need it for consistency of the semantic model. It’s in the realm of > things that isn’t

[swift-evolution] [Proposal draft] Limiting @objc inference

Hi all, Here’s a draft proposal to limit inference of @objc to only those places where we need it for consistency of the semantic model. It’s in the realm of things that isn’t *needed* for ABI stability, but if we’re going to make the source-breaking change here we’d much rather do it in the

Re: [swift-evolution] [Proposal] Enum string interoperability with Objective-C and Swift

The underline can be omitted. To remain more consistent. enum City: String { case NewYork = "New York" } typedef NSString * City; static City const CityNewYork = @"New York"; On Wed, Jan 4, 2017 at 2:22 PM Rod Brown wrote: > I'm not part of the core team, of

Re: [swift-evolution] [Proposal] Enum string interoperability with Objective-C and Swift

I'm not part of the core team, of course, but I like this change in principle. My one concern in this case would be choosing a naming convention for the back port that makes sense both ways. The naming convention you propose ( EnumName_EnumCase) seems inconsistent with the current import of

Re: [swift-evolution] [Proposal] Change (Dispatch)Data.withUnsafeBytes to use UnsafeMutableBufferPointer

Hi Andy, everyone, The short answer is that fixing struct Data requires a source breaking change (the enum for the deallocator has to change to use the raw buffer type), so I do not want to introduce it until Swift 4 provides a better transition path for this kind of change. - Tony > On Jan

Re: [swift-evolution] [Proposal] Change (Dispatch)Data.withUnsafeBytes to use UnsafeMutableBufferPointer

> On Dec 27, 2016, at 12:16 AM, Karl via swift-evolution > wrote: > > Looking for feedback before submitting a PR: > https://github.com/karwa/swift-evolution/blob/corelibs-unsafebytes/proposals/-corelibs-unsafebytes.md > >

Re: [swift-evolution] Move placement of 'throws' statement

I too am happy with the status quo. As a reminder, structured markup supports "- throws:" annotation -- E > On Jan 4, 2017, at 5:10 AM, Jeremy Pereira via swift-evolution > wrote: > >> >> On 3 Jan 2017, at 16:29, John McCall via swift-evolution >>

Re: [swift-evolution] Move placement of 'throws' statement

As I originally mentioned, once you are familiar with the facts that A) `throws` takes no parameters, and B) that `->` is returns, then I agree that iit is perfectly clear. My original (and still continuing, but getting better) confusion might make more sense after seeing the following

Re: [swift-evolution] Move placement of 'throws' statement

> On 3 Jan 2017, at 16:29, John McCall via swift-evolution > wrote: > > > > I'm sorry if people dislike the placement of "throws", but that ship has > sailed, > and any attempt to "fix" it at this point is just going to cause problems for > negligible benefit. >