Re: [swift-evolution] Swift Extensions on Overlay Structs

That's an interesting idea without having to write type signatures twice. The different nullability of the absoluteURL is strange indeed - what if I do a guaranteed cast from NSURL to URL, and absoluteURL would have been nil in the original object? Eiher way, I'd really like to know if URL

Re: [swift-evolution] guard let x = x

> On Nov 11, 2016, at 2:48 PM, Chris Lattner wrote: > >> To summarize: >> >> 1. Swift needs to introduce a `Result` type. > > Yes, but this is almost certainly a Swift 5 thing. We need to settle the > following arguments: > > 1) Does Result include async capabilities

Re: [swift-evolution] [swift-build-dev] Draft SwiftPM proposal: Multi-package repositories

> On Nov 12, 2016, at 9:54 PM, Daniel Dunbar wrote: >> >> >> It seems like you’re going through contortions to deal with arbitrary >> directory layouts and some odd consequences fall out of that decision. Not >> being able to deterministically detect non-unique

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

Sent from my iPhone > On Nov 13, 2016, at 4:03 PM, Austin Zheng wrote: > > I'd be happy to put something together, unless someone else wants to take it > on. Great, thanks! > > Doug, I also owe you a PR adding a minor amendment to one of the accepted > proposals.

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

Jean-Daniel, I agree with the first part of your assessment fully, which in my opinion is actually why I think the Kotlin style combined with the Swift style would pull in the best of both worlds and create a complete solution. I do share some of your reservation in the second part of your

Re: [swift-evolution] Symmetrical operators

Although you are correct in that the compiler wouldn't be able to guarantee that both "versions" would give the same answer, but that's currently the case anyway. Sent from my iPhone > On Nov 13, 2016, at 20:03, David Sweeris via swift-evolution > wrote: > > >>

Re: [swift-evolution] Symmetrical operators

> On Nov 13, 2016, at 19:04, arkadi daniyelian wrote: > > David, what about un-labeled parameters? If a function has 2 parameters of > the same type, how does compiler know which ones's which? If a function has two unlabeled parameters of the same type, you can already

Re: [swift-evolution] Symmetrical operators

David, what about un-labeled parameters? If a function has 2 parameters of the same type, how does compiler know which ones's which? > On Nov 13, 2016, at 9:49 PM, David Sweeris via swift-evolution > wrote: > > >> On Nov 13, 2016, at 1:38 PM, Андрей Володин via

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

I'd be happy to put something together, unless someone else wants to take it on. Doug, I also owe you a PR adding a minor amendment to one of the accepted proposals. I'll get to that this week. Austin On Sun, Nov 13, 2016 at 10:13 PM, Douglas Gregor via swift-evolution <

Re: [swift-evolution] Selector for current method

NSSelectorFromString(#function) works just fine for this already. > On Nov 13, 2016, at 6:50 PM, Rudolf Adamkovič via swift-evolution > wrote: > > Hi there! > > in Swift 3, we now have #selector and #keyPath yet there’s still no _cmd like > we have in Objective-C.

[swift-evolution] Selector for current method

Hi there! in Swift 3, we now have #selector and #keyPath yet there’s still no _cmd like we have in Objective-C. Example: class DirectoryListingStub: DirectoryListing { var cannedOutput: [Selector: Any?] = [ #selector(contentsOfDirectory(at:includingPropertiesForKeys:options:)):

Re: [swift-evolution] [swift-build-dev] Draft SwiftPM proposal: Multi-package repositories

On Sunday, November 13, 2016, David Hart via swift-build-dev < swift-build-...@swift.org> wrote: > If we're going down the road of KISS, why not require all packages to be > in direct sub-directories? Is that too constraining? Yes, I think so. Projects should be able to be in control of their

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

Recursive protocol constraints is one small-looking feature that could greatly improve the standard library. The generics manifesto describes it this way: "Currently, an associated type cannot be required to conform to its enclosing protocol (or any protocol that inherits that protocol). For

Re: [swift-evolution] Symmetrical operators

> On Nov 13, 2016, at 1:38 PM, Андрей Володин via swift-evolution > wrote: > > Hi, list! > > I’m thinking about proposal that would add a possibility to save some time on > creating symmetrical binary operators. > > The latest code example from my math lib: > >

[swift-evolution] Symmetrical operators

Hi, list! I’m thinking about proposal that would add a possibility to save some time on creating symmetrical binary operators. The latest code example from my math lib: @inline(__always) public static func *(lhs: Angle, rhs: Float) -> Angle { return Angle(lhs.degrees * rhs)

Re: [swift-evolution] [swift-build-dev] Draft SwiftPM proposal: Multi-package repositories

If we're going down the road of KISS, why not require all packages to be in direct sub-directories? Is that too constraining? I've read the proposal and I'm also concerned about the potential complexity. But I also like, as Daniel has said, that it allows the naive solution - simple

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

> Le 13 nov. 2016 à 03:37, Dennis Lysenko via swift-evolution > a écrit : > > That's a good point in Jay's example and from what I can tell a good way to > address it, Haravikk. > > I've done some work in a language that only provides type narrowing for >