Re: [swift-evolution] [Pitch] Can we make `default` on switches optional?

> On 4 Oct 2016, at 16:30, Tim Vermeulen via swift-evolution > wrote: > > I think I agree with you. The postfix `!` operator is always shorthand for > `fatalError()` (and some more syntax), and it would fit nicely with `default: > fatalError()`. > > The Swift usage of `?` is indeed different

[swift-evolution] [Question] Types of functions

// Swift 2.2print([Int].append.dynamicType) //=> inout Array -> Int -> ()print(print.dynamicType) //=> (Array>, String, String) -> () // Swift 3print(type(of: [Int].append)) //=> (inout Array) -> (Int) -> ()print(type(of: print)) //=> ((Array, String, String)) -> () Question #1: Methods are st

[swift-evolution] [Pitch] Several improvements points about extension and typealias

1. Allow extension specific dictionary e.g. extension Dictionary where Key == String, Value == String or extension Dictionary 2. Allow extending Equatable internally currently any type extend to Equatable should make theme public 3. Allow internal typealias for a public type this internal typeali

Re: [swift-evolution] [Pitch] Several improvements points about extension and typealias

~Robert Widmann 2016/10/05 11:00、Cao, Jiannan via swift-evolution のメッセージ: > 1. Allow extension specific dictionary > e.g. > extension Dictionary where Key == String, Value == String > or > extension Dictionary > This was just committed by Slava yesterday. > 2. Allow extending Equatable int

Re: [swift-evolution] SE-0111 and Curried argument labels: Unintended Consequences

I agree this seems like a pretty serious oversight. This is very un-swifty. Currying at one time was touted as a language feature, now it is more of an afterthought. -Jon From: mailto:swift-evolution-boun...@swift.org>> on behalf of Erica Sadun via swift-evolution mailto:swift-evolution@swif

Re: [swift-evolution] [Pitch] Several improvements points about extension and typealias

> On Oct 5, 2016, at 8:07 AM, Robert Widmann via swift-evolution > wrote: > > > > ~Robert Widmann > > 2016/10/05 11:00、Cao, Jiannan via swift-evolution > のメッセージ: > >> 1. Allow extension specific dictionary >> e.g. >> extension Dictionary where Key == Strin

Re: [swift-evolution] SE-0111 and Curried argument labels: Unintended Consequences

> On Oct 5, 2016, at 8:15 AM, Jon Akhtar via swift-evolution > wrote: > > I agree this seems like a pretty serious oversight. This is very un-swifty. > Currying at one time was touted as a language feature, now it is more of an > afterthought. I see it as a feature that has mostly been remov

Re: [swift-evolution] [Draft] Unify "import Darwin/Glibc" to simply "Libc"

There is also a similar intent for Zewo’s POSIX: https://github.com/Zewo/POSIX/blob/master/Sources/POSIX It would be great to have something included with Swift. > On Sep 14, 2016, at 5:59 AM, Alex Blewitt via swift-evolution > wrote: > > Vapor's Core package expresses a target called simply

Re: [swift-evolution] [Review] SE-0143: Conditional Conformances

> On Sep 30, 2016, at 5:59 PM, Dave Abrahams wrote: > > > on Fri Sep 30 2016, Douglas Gregor > wrote: > >>> On Sep 30, 2016, at 1:41 PM, Dave Abrahams wrote: >>> >>> >>> on Fri Sep 30 2016, Douglas Gregor wrote: >>> >> However, in cases where there is a

Re: [swift-evolution] [Draft] Unify "import Darwin/Glibc" to simply "Libc"

> On Sep 13, 2016, at 12:29 PM, Brian Gesiak via swift-evolution > wrote: > > I hadn't thought about a unified overlay for POSIX. I think the simplified > import alone has benefit to warrant its own evolution proposal. Would it be > possible to have a separate discussion for the POSIX overlay

Re: [swift-evolution] [Draft] Unify "import Darwin/Glibc" to simply "Libc"

On Wed, Oct 5, 2016 at 5:57 PM, Brent Royal-Gordon via swift-evolution < swift-evolution@swift.org> wrote: > > On Sep 13, 2016, at 12:29 PM, Brian Gesiak via swift-evolution < > swift-evolution@swift.org> wrote: > > > > I hadn't thought about a unified overlay for POSIX. I think the > simplified i

[swift-evolution] [Accepted] SE-0141: Availability by Swift version

Hello Swift community, Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0141-available-by-swift-version.md The review of SE-0141 "Availability by Swift version” ran

Re: [swift-evolution] [Draft] Unify "import Darwin/Glibc" to simply "Libc"

If we are pulling in functions/structures not defined by the C standard library or by POSIX, I’d be reluctant to support a standard name. It would be troublesome if someone thought that they were cross-platform but turned out to use strfry() heavily I certainly wonder what people specifically w

[swift-evolution] [Accepted] SE-0142: Permit where clauses to constrain associated types

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0142-associated-types-constraints.md Hello Swift Community, The review of SE-0142 "Permit where clauses to constra

Re: [swift-evolution] [Draft] Unify "import Darwin/Glibc" to simply "Libc"

On Wed, Oct 5, 2016 at 6:14 PM, David Waite via swift-evolution < swift-evolution@swift.org> wrote: > If we are pulling in functions/structures not defined by the C standard > library or by POSIX, I’d be reluctant to support a standard name. It would > be troublesome if someone thought that they w

[swift-evolution] Currying/Partial Application

Erica’s thread on currying made me remember a (very) early discussion on the topic where currying was being removed temporarily in hopes that partial application could be added back in later with better syntax. I would really like to be able to do the following: let partial = myFunc(a:

Re: [swift-evolution] [Pitch] Can we make `default` on switches optional?

> On Oct 5, 2016, at 8:29 AM, Haravikk via swift-evolution > wrote: > > >> On 4 Oct 2016, at 16:30, Tim Vermeulen via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> I think I agree with you. The postfix `!` operator is always shorthand for >> `fatalError()` (and some mor

Re: [swift-evolution] [Draft] Unify "import Darwin/Glibc" to simply "Libc"

> On Oct 5, 2016, at 4:14 PM, David Waite wrote: > > I certainly wonder what people specifically want to bring the C standard > library or POSIX libraries in for - is it compatibility with third party > libraries? Functionality missing in Foundation? I see a number of reasons: 1. Acce

Re: [swift-evolution] [Draft] Unify "import Darwin/Glibc" to simply "Libc"

> On Oct 5, 2016, at 6:38 PM, Brent Royal-Gordon via swift-evolution > wrote: > > Now, as for naming: I like using the leading "C" convention ("CLibc") because > it leaves us room for introducing an overlaid version of the module in the > future without breaking source compatibility. Because

Re: [swift-evolution] [Draft] Unify "import Darwin/Glibc" to simply "Libc"

> On Oct 5, 2016, at 7:08 PM, Greg Parker wrote: > >> Now, as for naming: I like using the leading "C" convention ("CLibc") >> because it leaves us room for introducing an overlaid version of the module >> in the future without breaking source compatibility. Because of this, I >> wouldn't want

Re: [swift-evolution] [Draft] Unify "import Darwin/Glibc" to simply "Libc"

On Wed, Oct 5, 2016 at 10:47 PM, Brent Royal-Gordon via swift-evolution < swift-evolution@swift.org> wrote: > > On Oct 5, 2016, at 7:08 PM, Greg Parker wrote: > > > >> Now, as for naming: I like using the leading "C" convention ("CLibc") > because it leaves us room for introducing an overlaid ver

[swift-evolution] [Pitch] inout with capture variable

for example: var a = 1 let block = { [inout a] in a += 1 } block() block() print(a) // 3 ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] inout with capture variable

You can currently achieve the same result if you remove `[inout a]` since `var`s are captured by reference. On Wed, Oct 5, 2016 at 9:06 PM, Cao Jiannan via swift-evolution < swift-evolution@swift.org> wrote: > for example: > > var a = 1 > > let block = { [inout a] in > a += 1 > } > > bloc

Re: [swift-evolution] [Pitch] inout with capture variable

> On Oct 5, 2016, at 9:06 PM, Cao Jiannan via swift-evolution > wrote: > > for example: > > var a = 1 > > let block = { [inout a] in > a += 1 > } > > block() > block() > > print(a) // 3 This is already how captures work by default in closures and nested functions in Swift: var a =

Re: [swift-evolution] [Pitch] inout with capture variable

so if developer want to capture an variable inference, must declare a new variable. class A { var value = 1 func test() -> () -> Int { var capturedValue = self.value let editInfo = { () -> Int in capturedValue += 1 return capturedValue

Re: [swift-evolution] [Draft] Unify "import Darwin/Glibc" to simply "Libc"

> On Oct 5, 2016, at 8:55 PM, Xiaodi Wu wrote: > > See, I'd assumed that the "unified" Darwin/Glibc would simply be what you > call Platform. And if we're going to have that overlay, what's the point of > also renaming Darwin/Glibc to CPlatform, given that it's going to be > different between

Re: [swift-evolution] [Pitch] inout with capture variable

> On Oct 5, 2016, at 10:07 PM, Cao Jiannan wrote: > > so if developer want to capture an variable inference, must declare a new > variable. I don’t follow what you mean here. > > class A { > var value = 1 > > func test() -> () -> Int { > var capturedValue = self.value >

Re: [swift-evolution] [Pitch] inout with capture variable

I just want to demo how the inout capture works. the demo code just want to capture value avoiding capture self. > > On Oct 5, 2016, at 10:07 PM, Cao > > Jiannanmailto:frog...@163.com)>wrote: > > so if developer want to capture an variable inference, must declare a new > > variable. > I don’t f

Re: [swift-evolution] [Draft] Unify "import Darwin/Glibc" to simply "Libc"

On Oct 5, 2016, at 3:57 PM, Brent Royal-Gordon wrote: >> On Sep 13, 2016, at 12:29 PM, Brian Gesiak via swift-evolution >> wrote: >> I hadn't thought about a unified overlay for POSIX. I think the simplified >> import alone has benefit to warrant its own evolution proposal. Would it be >> poss