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

> 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

Re: [swift-evolution] Disallowing unreachable code

>> 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”

Re: [swift-evolution] Disallowing unreachable code

> 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”

Re: [swift-evolution] Disallowing unreachable code

> 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

Re: [swift-evolution] Disallowing unreachable code

> 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

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] [Review] SE-0159: Fix Private Access Levels

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

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

> 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

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

+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 >> > wrote: >> >> sources: This property defines the

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,