Re: [swift-evolution] [Pitch] Allow closures/default params to satisfy protocol requirements

I would be in favor of some sugar allowing optional methods eventually. I am kind of waiting to see how the reflection API shakes out. I know there was some sort of argument on the list before about it being bad design to have optional methods, but I still really like it as a pattern. In

Re: [swift-evolution] [Pitch] Allow closures/default params to satisfy protocol requirements

I will consider your advice, it’s actually a replay good one. :) I guess it was the iOS development influence from Objective-C that let me write such not swifty delegates. --  Adrian Zubarev Sent with Airmail Am 29. März 2017 um 04:07:38, Slava Pestov (spes...@apple.com) schrieb: On Mar

Re: [swift-evolution] [Pitch] Allow closures/default params to satisfy protocol requirements

> On Mar 28, 2017, at 12:10 AM, Adrian Zubarev > wrote: > > It’s probably the influence from iOS development where I have delegate > protocols like this one: > > @objc public protocol _ContainerViewControllerDelegate: class { > > @objc optional func

Re: [swift-evolution] [Pitch] Allow closures/default params to satisfy protocol requirements

The core team did call it a future "purely additive proposal"--implying that there does need to be one written. I do believe that someone did make a start at implementing compound names, which was not merged as-is because there has been no proposal. Should be an easy and uncontroversial one to

Re: [swift-evolution] [Pitch] Allow closures/default params to satisfy protocol requirements

Thanks for that link, it definitely solves the label issue, and even some label issues I didn't consider; for example, you couldn't implement BidirectionalCollection using closures without it: let index: (Index)->Index // should be index(before:) let index:

Re: [swift-evolution] [Pitch] Allow closures/default params to satisfy protocol requirements

Theoretically speaking optional could potentially become some language sugar right? protocol P { // Variable with label var foo(a:) : ((Int) -> Void)? { get } // more sugared version var foo: ((a: Int) -> Void)? { get } } extension P { // (1) var foo: ((a: Int) ->

Re: [swift-evolution] [Pitch] Allow closures/default params to satisfy protocol requirements

It’s probably the influence from iOS development where I have delegate protocols like this one: @objc public protocol _ContainerViewControllerDelegate: class { @objc optional func containerViewController(_ containerViewController: ContainerViewController,

Re: [swift-evolution] [Pitch] Allow closures/default params to satisfy protocol requirements

> On Mar 27, 2017, at 1:48 PM, Adrian Zubarev via swift-evolution > wrote: > > Assuming we’ll get that functionality, both var and let should satisfy the > protocol requirements right? > In theory, there’s no reason not to allow that. > If it is valid, could we

Re: [swift-evolution] [Pitch] Allow closures/default params to satisfy protocol requirements

I really like the roadmap the core team has come up with. The only critic I personally would have is the need of the comma in var op(lhs:,rhs:) : (Int, Int) -> Int. To me it would be consistent enough with selectors if there wasn’t any comma var op(lhs:rhs:) : (Int, Int) -> Int. I have a few

Re: [swift-evolution] [Pitch] Allow closures/default params to satisfy protocol requirements

Can’t promise I’m up to the task as I have only dipped my toes in AST and Sema but can give it a try if you want. > On 27 Mar 2017, at 16:28, Matthew Johnson via swift-evolution > wrote: > >> >> On Mar 26, 2017, at 8:01 PM, Slava Pestov >

Re: [swift-evolution] [Pitch] Allow closures/default params to satisfy protocol requirements

> On Mar 26, 2017, at 8:01 PM, Slava Pestov wrote: > >> >> On Mar 26, 2017, at 5:32 PM, Matthew Johnson > > wrote: >> >> >> >> Sent from my iPad >> >> On Mar 26, 2017, at 7:03 PM, Slava Pestov via swift-evolution

Re: [swift-evolution] [Pitch] Allow closures/default params to satisfy protocol requirements

> On Mar 26, 2017, at 5:32 PM, Matthew Johnson wrote: > > > > Sent from my iPad > > On Mar 26, 2017, at 7:03 PM, Slava Pestov via swift-evolution > > wrote: > >> >>> On Mar 26, 2017, at 11:12 AM, Karl

Re: [swift-evolution] [Pitch] Allow closures/default params to satisfy protocol requirements

Sent from my iPad > On Mar 26, 2017, at 7:03 PM, Slava Pestov via swift-evolution > wrote: > > >> On Mar 26, 2017, at 11:12 AM, Karl Wagner via swift-evolution >> wrote: >> >> I’d like to pitch the following two language changes. Both

Re: [swift-evolution] [Pitch] Allow closures/default params to satisfy protocol requirements

> On Mar 26, 2017, at 11:12 AM, Karl Wagner via swift-evolution > wrote: > > I’d like to pitch the following two language changes. Both of them are > technically possible today if you manually write thunks for the relevant > protocol requirements, but it would be

Re: [swift-evolution] [Pitch] Allow closures/default params to satisfy protocol requirements

I failed to mention that It is currently possible to create a protocol extension with a default argument, but this is not ideal. This has made the topic complex enough to warrant a new thread and I will not hijack this thread any longer. If anyone is interested, I will start a new thread for

Re: [swift-evolution] [Pitch] Allow closures/default params to satisfy protocol requirements

A comment: Your description of #2 is a little confusing. Functions with default arguments can currently satisfy protocols. Perhaps it should be “Allow functions with extra default arguments to satisfy protocols" I have not had the need for the features you mentioned, but it would be nice to

Re: [swift-evolution] [Pitch] Allow closures/default params to satisfy protocol requirements

I'm in favor of both of these. However, the issue outlined in (1) with respect to labels is problematic. The core team's post-Swift 3 plan ( https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000233.html) for evolving from SE-0111 solves that problem without the need to invent

Re: [swift-evolution] [Pitch] Allow closures/default params to satisfy protocol requirements

> On Mar 26, 2017, at 11:12, Karl Wagner via swift-evolution > wrote: > > I’d like to pitch the following two language changes. Both of them are > technically possible today if you manually write thunks for the relevant > protocol requirements, but it would be nice

[swift-evolution] [Pitch] Allow closures/default params to satisfy protocol requirements

I’d like to pitch the following two language changes. Both of them are technically possible today if you manually write thunks for the relevant protocol requirements, but it would be nice if we allowed them to be written directly: 1) Allow closures to satisfy function requirements in protocols