Re: [swift-evolution] [Idea] Remove optional pattern binding

016, at 11:47 AM, Chris Lattner <clatt...@apple.com > > <mailto:clatt...@apple.com>> wrote: > > On May 2, 2016, at 11:12 AM, John McCall via swift-evolution > > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > >> > >>

Re: [swift-evolution] [Idea] Remove optional pattern binding

> On May 2, 2016, at 11:47 AM, Chris Lattner <clatt...@apple.com> wrote: > On May 2, 2016, at 11:12 AM, John McCall via swift-evolution > <swift-evolution@swift.org> wrote: >> >>> On May 2, 2016, at 9:39 AM, Jordan Rose via swift-evolution >>> <

Re: [swift-evolution] [Idea] Remove optional pattern binding

> On May 2, 2016, at 9:39 AM, Jordan Rose via swift-evolution > wrote: >> On May 1, 2016, at 13:09, Brent Royal-Gordon via swift-evolution >> wrote: >> >>> Pattern binding for optionals will look like: >>> >>> if let x? = y { ... } >> >>

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

> On May 2, 2016, at 6:55 AM, David Sweeris via swift-evolution > wrote: > I was just thinking that: > protocol Foo : reference {} > might be more to the point than: > protocol Foo : class {} > > I know that it’s currently a moot point because classes are the only* >

Re: [swift-evolution] [Review] SE-0017: Change Unmanaged to use UnsafePointer

> On Apr 28, 2016, at 11:10 AM, Chris Lattner via swift-evolution > wrote: > Hello Swift community, > > The review of "SE-0017: Change Unmanaged to use UnsafePointer" begins now and > runs through May 3. The proposal is available here: > > >

Re: [swift-evolution] [swift-dev] [Compiler] Help IR gen in targetting MSVC

> On Apr 26, 2016, at 1:03 PM, Sangjin Han wrote: > The problem can be solved by modifying that code. Thanks you. I thought that > code will affect only to the CLong type not Int. It changes what 'long' gets imported as. If there's a Windows API defined using 'long'

Re: [swift-evolution] Mutability for Foundation types in Swift

> On Apr 25, 2016, at 10:32 AM, Douglas Gregor via swift-evolution > wrote: >> On Apr 25, 2016, at 9:20 AM, Tony Parker via swift-evolution >> > wrote: >> >> Hi Brent, >> >> Thanks for your feedback!

Re: [swift-evolution] ValueEnumerable protocol with derived implementation for enums

> On Apr 22, 2016, at 11:48 PM, Jacob Bandes-Storch wrote: > On Fri, Apr 22, 2016 at 11:34 PM, John McCall > wrote: >> On Apr 22, 2016, at 11:11 PM, Jacob Bandes-Storch > >

Re: [swift-evolution] ValueEnumerable protocol with derived implementation for enums

> On Apr 22, 2016, at 11:11 PM, Jacob Bandes-Storch wrote: > On Fri, Apr 22, 2016 at 10:50 PM, John McCall > wrote: > > I have not been following this discussion, but I would be extremely antsy > about guaranteeing any

Re: [swift-evolution] ValueEnumerable protocol with derived implementation for enums

> On Apr 22, 2016, at 10:18 PM, Jacob Bandes-Storch wrote: > On Sat, Apr 16, 2016 at 5:20 AM, plx via swift-evolution > > wrote: > > > My 2c is that if this is to go in the standard library, it should be done >

Re: [swift-evolution] [swift-dev] Lazy var and deinit

> On Apr 21, 2016, at 2:29 AM, Alexandr.moq via swift-dev > wrote: > Should SWIFT initialize a variable in deinit method if it has not been > initialized? > > For example: > ```swift > class A { > lazy var b = B() > deinit { > b.clean() >

Re: [swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"

> On Apr 15, 2016, at 2:47 PM, Joe Groff <jgr...@apple.com> wrote: >> On Apr 15, 2016, at 11:43 AM, John McCall <rjmcc...@apple.com> wrote: >>> On Apr 15, 2016, at 10:41 AM, Joe Groff <jgr...@apple.com> wrote: >>>> On Apr 15, 2016, at 8:29 AM, John M

Re: [swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"

> On Apr 15, 2016, at 10:41 AM, Joe Groff <jgr...@apple.com> wrote: >> On Apr 15, 2016, at 8:29 AM, John McCall via swift-evolution >> <swift-evolution@swift.org> wrote: >> >>> On Apr 14, 2016, at 10:50 PM, Chris Lattner <clatt...@apple.com> wrot

Re: [swift-evolution] TreeLiteralConvertible

> On Apr 15, 2016, at 1:29 AM, Milos Rankovic > wrote: >> On 15 Apr 2016, at 03:22, John McCall > > wrote: >> Your JSON literal example is already pretty well modeled by simply making a >> JSONValue type that

Re: [swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"

> On Apr 14, 2016, at 10:50 PM, Chris Lattner wrote: > On Apr 14, 2016, at 10:40 PM, John McCall wrote: To me, the unparenthesized style suggests that the input and output are peers, which feels more natural for the sort of value-to-value

Re: [swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"

> On Apr 14, 2016, at 10:28 PM, Chris Lattner wrote: > > On Apr 14, 2016, at 10:21 PM, John McCall wrote: >> >>> On Apr 14, 2016, at 9:57 PM, Chris Lattner via swift-evolution >>> wrote: >>> >>> We currently accept function

Re: [swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"

> On Apr 14, 2016, at 9:57 PM, Chris Lattner via swift-evolution > wrote: > > We currently accept function type syntax without parentheses, like: > > Int -> Float > String -> () > > etc. The original rationale aligned with the fact that we wanted to treat > all

Re: [swift-evolution] TreeLiteralConvertible

> On Apr 14, 2016, at 2:56 PM, Milos Rankovic > wrote: > Hi John and Brent, > >> On 14 Apr 2016, at 22:22, John McCall > > wrote: >> >> multiple-conformance idea doesn't work > > > The idea is not

Re: [swift-evolution] TreeLiteralConvertible

> On Apr 14, 2016, at 2:20 PM, Brent Royal-Gordon > wrote: >> No, you just need Tree to conform to both ArrayLiteralConvertible and >> IntegerLiteralConvertible, and it implements the latter by building a Value >> out of it. > > That not only doesn't work if your type

Re: [swift-evolution] TreeLiteralConvertible

> On Apr 14, 2016, at 2:03 PM, Milos Rankovic > wrote: >> On 14 Apr 2016, at 21:36, John McCall > > wrote: >> >> No, you just need Tree to conform to both ArrayLiteralConvertible and >> IntegerLiteralConvertible, and

Re: [swift-evolution] TreeLiteralConvertible

> On Apr 14, 2016, at 1:34 PM, Milos Rankovic > wrote: > Hi John, > >> On 14 Apr 2016, at 21:09, John McCall > > wrote: >> >> I mean, you could just make your Tree type implement all the individual >>

Re: [swift-evolution] TreeLiteralConvertible

> On Apr 14, 2016, at 12:01 PM, Milos Rankovic via swift-evolution > wrote: > Hi Andrey and Laurent, > >> On 14 Apr 2016, at 19:23, Andrey Tarantsov > > wrote: >> >> Can you please give us a few real-world examples

Re: [swift-evolution] [Review] SE-0055 Make unsafe pointer nullability explicit using Optional

> On Mar 30, 2016, at 3:11 AM, Jeremy Pereira via swift-evolution > wrote: >> On 25 Mar 2016, at 23:00, Brent Royal-Gordon via swift-evolution >> wrote: >> >>> In the low level world, there is no such thing as an invalid address; both >>>

Re: [swift-evolution] [Review] SE-0055 Make unsafe pointer nullability explicit using Optional

> On Mar 24, 2016, at 9:43 PM, Chris Lattner <clatt...@apple.com> wrote: > On Mar 24, 2016, at 7:28 PM, John McCall via swift-evolution > <swift-evolution@swift.org> wrote: >> I'd actually be much more concerned about the pervasive assumptions about >> pointer

Re: [swift-evolution] Better syntax for deferred?

> On Jan 4, 2016, at 12:41 PM, Howard Lovatt via swift-evolution > wrote: > I don’t think it is worth changing from defer to the more traditional try > finally block, both have pros and cons. Just work with what we have. You can > always, as a matter of style, put a

Re: [swift-evolution] [Proposal draft] Generalized Naming for Any Function

> On Dec 28, 2015, at 1:14 PM, Joe Groff wrote: >> On Dec 28, 2015, at 1:09 PM, Brent Royal-Gordon >> wrote: >> >>> and you could access the unapplied lens for an instance property using >>> `Type.property` syntax, analogous to how `Type.method`

Re: [swift-evolution] Why aren't source to source transformations part of the Swift language standard?

> On Dec 29, 2015, at 11:40 AM, Amir Michail via swift-evolution > wrote: >> On Dec 29, 2015, at 2:34 PM, Jacob Bandes-Storch > > wrote: >> >> I would not recommend phrasing these proposals as "Why doesn't Swift already

Re: [swift-evolution] [Proposal draft] Generalized Naming for Any Function

> On Dec 27, 2015, at 4:02 PM, Chris Lattner via swift-evolution > wrote: > On Dec 27, 2015, at 10:37 AM, Joe Groff via swift-evolution > > wrote: >>> can be correctly parsed as a reference to

Re: [swift-evolution] Proposal - Allow properties in Extensions

> On Dec 23, 2015, at 7:05 AM, Paul Cantrell <cantr...@pobox.com> wrote: > On Dec 22, 2015, at 10:45 PM, John McCall via swift-evolution > <swift-evolution@swift.org> wrote: >> >> when you stuff a lot of functionality into a single class in most OO >> la

Re: [swift-evolution] [Pitch] Replace 'inout' with '&'

> On Dec 21, 2015, at 11:19 AM, Jordan Rose via swift-evolution > wrote: >> On Dec 21, 2015, at 10:27 , Joe Groff > > wrote: >> >> >>> On Dec 19, 2015, at 7:12 PM, Dmitri Gribenko via swift-evolution >>>

Re: [swift-evolution] Readwrite reflection in Swift

> On Dec 17, 2015, at 11:21 PM, Gergely Orosz via swift-evolution > wrote: > (forwarding a discussion on Swift reflection from swift-users) > > It seems there is no disagreement on how reflection is something we would > want in Swift. Given that until this is part of

<    1   2   3   4   5