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

2017-03-28 Thread Adrian Zubarev via swift-evolution
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

2017-03-28 Thread Adrian Zubarev via swift-evolution
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) -> V

Re: [swift-evolution] [swift-build-dev] [Draft] Package Manager Custom Targets Layout

2017-03-28 Thread Jens Nerup via swift-evolution
+1 > On 27 Mar 2017, at 07.27, Brent Royal-Gordon via swift-build-dev > wrote: > >> On Mar 24, 2017, at 1:26 PM, Ankit Aggarwal via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> sources: This property defines the source files to be included in the >> target, relative to

Re: [swift-evolution] [Draft] Package Manager Custom Targets Layout

2017-03-28 Thread Ankit Aggarwal via swift-evolution
> Is the default *not* recursively searching for source files? If not, it > would be great to have ways that achieve that, e.g. `*.swift`. > The default *is* searching recursively. There will be globbing support in future that allows `*.swift` but for now we will (recursively) search for valid sou

Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels

2017-03-28 Thread Vladimir.S via swift-evolution
On 28.03.2017 1:33, Xiaodi Wu wrote: Note that allowing nested extensions will require breaking rules for access modifiers on all extensions. This is because, during revisions for SE-0025, the idea of aligning rules for extensions to rules for types was brought up and rejected. Subsequent proposa

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

2017-03-28 Thread Karl Wagner via swift-evolution
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: (Index)->Ind

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

2017-03-28 Thread Xiaodi Wu via swift-evolution
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 writ

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

2017-03-28 Thread Slava Pestov via swift-evolution
> 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 containerViewController(_ contain

Re: [swift-evolution] Disallowing unreachable code

2017-03-28 Thread Chris Lattner via swift-evolution
> On Mar 27, 2017, at 10:25 AM, John McCall via swift-evolution > wrote: > >> On Mar 24, 2017, at 6:54 PM, Peter Dillinger via swift-evolution >> wrote: >> I don't see anything directly relevant to this in the archives, and I >> haven't prepared a detailed proposal. But I'm raising the gene

Re: [swift-evolution] Disallowing unreachable code

2017-03-28 Thread Peter Dillinger via swift-evolution
> Agreed, we have the right design here. The go community has shown the result > of taking > a hard line on this, and it really hurts refactoring and other experimental > “pound out some > code” prototyping use cases. We use warnings for things that “should be > cleaned up before > code is com

Re: [swift-evolution] Disallowing unreachable code

2017-03-28 Thread Chris Lattner via swift-evolution
> On Mar 28, 2017, at 9:40 PM, Peter Dillinger > wrote: > >> Agreed, we have the right design here. The go community has shown the >> result of taking >> a hard line on this, and it really hurts refactoring and other experimental >> “pound out some >> code” prototyping use cases. We use war

Re: [swift-evolution] Disallowing unreachable code

2017-03-28 Thread Peter Dillinger via swift-evolution
>> On Mar 28, 2017, at 9:40 PM, Peter Dillinger >> wrote: >>> Agreed, we have the right design here. The go community has shown the >>> result of taking >>> a hard line on this, and it really hurts refactoring and other experimental >>> “pound out some >>> code” prototyping use cases. We use

Re: [swift-evolution] [Pitch] Localized Swift Frameworks

2017-03-28 Thread Chris Lattner via swift-evolution
> On Mar 24, 2017, at 10:28 AM, Jeff Kelley via swift-evolution > wrote: > > One of the things that struck me from today’s Apple press release about Swift > Playgrounds being localized in more languages is this screenshot: > > > > All of the UI is fully localized for Chinese, except the act

Re: [swift-evolution] Disallowing unreachable code

2017-03-28 Thread David Sweeris via swift-evolution
On Mar 28, 2017, at 21:55, Peter Dillinger via swift-evolution wrote: On Mar 28, 2017, at 9:40 PM, Peter Dillinger wrote: Agreed, we have the right design here. The go community has shown the result of taking a hard line on this, and it really hurts refactoring and

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

2017-03-28 Thread Adrian Zubarev via swift-evolution
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 28,