Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

> On Jan 12, 2018, at 6:47 PM, Dave DeLong via swift-evolution > wrote: > > I feel like we’re talking past each other right now, so I’ll give a concrete > example: > > Let’s say MyAwesomeFramework.framework defines this enum: > > enum Access { > case none >

Re: [swift-evolution] [Pitch] Make try? + optional chain flattening work together

> On Jan 12, 2018, at 12:53 PM, BJ Homer via swift-evolution > wrote: > > I agree that this behavior is annoying. However, wouldn’t it be > source-breaking to change this now? Source compatibility means that we can't change the behavior of Swift 3 / Swift 4

Re: [swift-evolution] extension of AnyObject

> On Dec 29, 2017, at 11:21 PM, Kenny Leung via swift-evolution > wrote: > > Hi All. > > I just discovered that you can’t write an extension on AnyObject. What’s the > reasoning behind this? > > I’m trying to write my own version of KeyValueObserving, and it would

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

> On Dec 31, 2017, at 1:21 PM, Cheyo Jimenez wrote: > > > > On Dec 31, 2017, at 8:59 AM, Ben Rimmington via swift-evolution > wrote: > >>> On 21 Dec 2017, at 03:32, John McCall wrote: >>> > On Dec 20, 2017, at 10:16 PM, Brent

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

M, Matthew Johnson <matt...@anandabits.com >>> <mailto:matt...@anandabits.com>> wrote: >>> >>> >>>> On Dec 21, 2017, at 1:26 PM, John McCall via swift-evolution >>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>>

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

> On Dec 21, 2017, at 2:41 PM, Matthew Johnson <matt...@anandabits.com> wrote: > > >> On Dec 21, 2017, at 1:26 PM, John McCall via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >>> >>&g

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

> On Dec 21, 2017, at 2:03 PM, Jordan Rose via swift-evolution > wrote: > > > >> On Dec 20, 2017, at 12:35, Karl Wagner > > wrote: >> >> >> >>> On 20. Dec 2017, at 19:54, Jordan Rose >>

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

> On Dec 20, 2017, at 10:16 PM, Brent Royal-Gordon via swift-evolution > wrote: > >> On Dec 19, 2017, at 2:58 PM, Ted Kremenek via swift-evolution >> wrote: >> >> • What is your evaluation of the proposal? > > I am pleased with the

[swift-evolution] [Accepted with revisions] SE-0187 “Introduce Sequence.filterMap(_:)”

Hi, Swift community! I apologize for the delay in reporting our decision here; between one holiday and the other, it took awhile for the core team to assemble a quorum to talk through this. Proposal Link:

Re: [swift-evolution] Proposal and Timeline for Discourse Transition

d to this position, too. John. > > On Dec 14, 2017, at 11:01 AM, John McCall via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > >> >>> On Dec 14, 2017, at 1:38 AM, Nicole Jacque <jac...@apple.com >>&g

Re: [swift-evolution] Proposal and Timeline for Discourse Transition

ift. John. > >> On Dec 13, 2017, at 9:58 PM, John McCall via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >>> On Dec 13, 2017, at 6:00 PM, Jonathan Hull via swift-evolution >>> <swift-evolution@

Re: [swift-evolution] Proposal and Timeline for Discourse Transition

> On Dec 13, 2017, at 6:00 PM, Jonathan Hull via swift-evolution > wrote: > I would also like a place in the “Using Swift” for working on libraries or > open source projects. I think asking for collaborators is fundamentally > different than asking technical

Re: [swift-evolution] Proposal and Timeline for Discourse Transition

> On Dec 12, 2017, at 3:28 PM, Alejandro Martinez wrote: > > Yes that's what I was suggesting. > My view is that different kind of conversations would happen in a > "help" vs. "announcements" category. Some people may be interested in > being up to date with the more

Re: [swift-evolution] Proposal and Timeline for Discourse Transition

> On Dec 12, 2017, at 1:36 PM, Alejandro Martinez via swift-evolution > wrote: > > On Tue, Dec 12, 2017 at 4:15 PM, Kelvin Ma > wrote: >> >> >> On Tue, Dec 12, 2017 at 5:31 AM, Alejandro Martinez via

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

> On Nov 27, 2017, at 1:43 AM, David Hart wrote: > On 27 Nov 2017, at 07:32, John McCall > wrote: > >> >>> On Nov 22, 2017, at 2:01 AM, David Hart via swift-evolution >>>

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

> On Nov 22, 2017, at 2:01 AM, David Hart via swift-evolution > wrote: > > > >> On 22 Nov 2017, at 07:48, David Hart via swift-evolution >> > wrote: >> >> >> >> On 22 Nov 2017, at 07:41, Douglas

Re: [swift-evolution] [Pitch] Make Optional, Array, and Dictionary conditionally Equatable

> On Nov 22, 2017, at 1:08 PM, Douglas Gregor via swift-evolution > wrote: > > > > Sent from my iPhone > > On Nov 22, 2017, at 9:48 AM, Chris Lattner > wrote: > >> IMO this is obvious and you should put it in.

Re: [swift-evolution] [swift-evolution-announce] [Accepted and Focused Re-review] SE-0187: Introduce Sequence.filterMap(_:)

> On Nov 20, 2017, at 12:22 PM, BJ Homer wrote: >> On Nov 20, 2017, at 10:09 AM, Drew Crawford via swift-evolution >> > wrote: >> >> The typical case for this function in my code is the identity closure, that >> is

Re: [swift-evolution] [Accepted and Focused Re-review] SE-0187: Introduce Sequence.filterMap(_:)

> On Nov 15, 2017, at 9:16 PM, Greg Parker wrote: > > >> On Nov 15, 2017, at 5:53 PM, John McCall > > wrote: >> >>> On Nov 15, 2017, at 7:36 PM, Greg Parker via swift-evolution >>>

Re: [swift-evolution] [Accepted and Focused Re-review] SE-0187: Introduce Sequence.filterMap(_:)

> On Nov 15, 2017, at 7:36 PM, Greg Parker via swift-evolution > wrote: > >> >> On Nov 15, 2017, at 2:31 PM, BJ Homer via swift-evolution >> > wrote: >> >>> On Nov 15, 2017, at 3:05 PM, Tino Heth via

[swift-evolution] [Accepted and Focused Re-review] SE-0187: Introduce Sequence.filterMap(_:)

Hello, Swift Community! The initial review of "SE-0187: Introduce Sequence.filterMap(_:)" ran through yesterday, November 14th, 2017. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0187-introduce-filtermap.md

Re: [swift-evolution] [Pitch] Improving capturing semantics of local functions

> On Nov 12, 2017, at 11:11 PM, Brent Royal-Gordon via swift-evolution > wrote: > >> On Nov 12, 2017, at 12:55 AM, David Hart via swift-evolution >> wrote: >> >> Hello evolution folks, >> >> After the positive feedback on the idea of

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

> On Nov 8, 2017, at 3:20 PM, Tino Heth via swift-evolution > wrote: >> This is a wonderful example! But it’s an argument for a different discussion >> (of general usefulness of implicit optional promotion). Thanks to the >> optional promotion, what the closure

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

ift.org>> wrote: >>> >>> On Tue, Nov 7, 2017, at 03:23 PM, John McCall via swift-evolution wrote: >>>> https://github.com/apple/swift-evolution/blob/master/proposals/0187-introduce-filtermap.md >>>> >>>> <https://github.com/a

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

> On Nov 7, 2017, at 6:34 PM, Kevin Ballard via swift-evolution > <swift-evolution@swift.org> wrote: > > On Tue, Nov 7, 2017, at 03:23 PM, John McCall via swift-evolution wrote: >> https://github.com/apple/swift-evolution/blob/master/proposals/0187-introduce-fil

[swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

Hello, Swift community! The review of "SE-0187: Introduce Sequence.filterMap(_:)" begins now and runs through November 14th, 2017. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0187-introduce-filtermap.md

Re: [swift-evolution] [Discussion] Swift for Data Science / ML / Big Data analytics

> On Oct 31, 2017, at 12:43 AM, Chris Lattner wrote: > > JohnMC: question for you below. > > On Oct 30, 2017, at 1:25 PM, Douglas Gregor > wrote: >>> >>> Thinking about the Perl case makes it clear to me that this should not

Re: [swift-evolution] Making capturing semantics of local

> On Oct 28, 2017, at 6:05 AM, Johannes Weiß via swift-evolution > wrote: > > Hi Mike, > >> On 27 Oct 2017, at 7:05 pm, Mike Kluev wrote: >> >> on Date: Fri, 27 Oct 2017 17:52:54 +0100 Johannes Weiß >> wrote: >>

Re: [swift-evolution] stack classes

> On Oct 27, 2017, at 9:27 AM, Mike Kluev via swift-evolution > wrote: > > if it wasn't already discussed here is the preliminary proposal, if it was > then my +1 to the feature. > > i propose we have an explicit apparatus to denote classes having stack > storage.

Re: [swift-evolution] Making capturing semantics of local

> On Oct 26, 2017, at 3:24 PM, David Hart <da...@hartbit.com> wrote: >> On 26 Oct 2017, at 21:16, John McCall via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >>> On Oct 26, 2017, at 2:19 PM, Mike

Re: [swift-evolution] Making capturing semantics of local functions explicit

> On Oct 25, 2017, at 4:21 PM, David Hart wrote: >> On 25 Oct 2017, at 19:01, John McCall > > wrote: >> >>> On Oct 25, 2017, at 7:41 AM, David Hart via swift-evolution >>>

Re: [swift-evolution] Making capturing semantics of local functions explicit

> On Oct 25, 2017, at 7:41 AM, David Hart via swift-evolution > wrote: > I got bit again by a sneaky memory leak concerning local functions and would > like to discuss a small language change. I vaguely remember this being > discussed in the past, but can’t find the

Re: [swift-evolution] superscripts, subscripts, etc.

> On Oct 5, 2017, at 2:31 AM, Taylor Swift via swift-evolution > wrote: > not to rain on anyone’s parade here but y’all are aware unicode superscripts > don’t even form a complete alphabet right? This kind of syntax would really > only work for positive integer

Re: [swift-evolution] Question about async await

> On Sep 25, 2017, at 3:14 PM, Jean-Daniel via swift-evolution > wrote: >> Le 25 sept. 2017 à 18:54, Trevör Anne Denise via swift-evolution >> > a écrit : >> >>> >>> Le 25 sept. 2017 à 13:33, Trevör ANNE

Re: [swift-evolution] Subscripts assignable to closure vars

> On Sep 15, 2017, at 3:45 PM, Joanna Carter via swift-evolution > wrote: > > Just came across this. > > I want to be able to hold onto the reference to a subscript "method" for > later use. > > Assigning the subscript to a var in the init of a type raises a

Re: [swift-evolution] [Concurrency] async/await + actors

> On Sep 12, 2017, at 2:19 AM, Pierre Habouzit via swift-evolution > wrote: > >> On Sep 11, 2017, at 9:00 PM, Chris Lattner via swift-evolution >> > wrote: >> >> On Sep 4, 2017, at 12:18 PM, Pierre

Re: [swift-evolution] [Concurrency] async/await + actors

> On Sep 2, 2017, at 3:19 PM, Pierre Habouzit via swift-evolution > wrote: > >> On Sep 2, 2017, at 11:15 AM, Chris Lattner > > wrote: >> >> On Aug 31, 2017, at 7:24 PM, Pierre Habouzit >

Re: [swift-evolution] Beyond Typewriter-Styled Code in Swift, Adoption of Symbols

> On Sep 1, 2017, at 2:33 PM, David Sweeris <daveswee...@mac.com> wrote: > > >> On Aug 31, 2017, at 6:27 PM, John McCall via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> I would argue th

Re: [swift-evolution] Beyond Typewriter-Styled Code in Swift, Adoption of Symbols

> On Sep 1, 2017, at 6:04 AM, André “Zephyz” Videla > wrote: > >> It's not a group operation, but it is consistent with the concept of scalar >> multiplication in a vector space. > > That is exactly what I am suggesting: Have a dedicated scalar multiplication >

Re: [swift-evolution] Beyond Typewriter-Styled Code in Swift, Adoption of Symbols

> On Aug 31, 2017, at 8:51 PM, André “Zephyz” Videla via swift-evolution > wrote: >> these versions of the math operators don't quite work the same way as the >> standard ones (e.g. `+` can throw), but they still carry math semantics > > > That is exactly what I

Re: [swift-evolution] Beyond Typewriter-Styled Code in Swift, Adoption of Symbols

> On Aug 31, 2017, at 3:16 PM, Taylor Swift via swift-evolution > wrote: > Where is the source for this number? XCode is not even available for Linux. > And XCode’s market share is only shrinking as Swift expands more into the > open source world. To make Swift

Re: [swift-evolution] Retain cycles in closures

> On Aug 30, 2017, at 7:02 PM, Yvo van Beek wrote: > > Hi John, > > I see that I've used DispatchQueue.main in my example which is probably a > poor choice to demonstrate the issue: > > class MyClass { > let queue = DispatchQueue(label: "MyApp.MyQueue") > > func

Re: [swift-evolution] Retain cycles in closures

> On Aug 30, 2017, at 6:45 PM, Yvo van Beek via swift-evolution > wrote: > > When I'm writing code I like it to be free from any distractions that aren't > really relevant to the problem that I'm trying to solve. One of these > distractions is having to pay a lot

Re: [swift-evolution] typed throws

> On Aug 25, 2017, at 12:18 PM, Dave Abrahams via swift-evolution > <swift-evolution@swift.org> wrote: > on Fri Aug 18 2017, Joe Groff <swift-evolution@swift.org> wrote: > >>> On Aug 17, 2017, at 11:27 PM, John McCall via swift-evolution >

Re: [swift-evolution] [Concurrency] do async

> On Aug 23, 2017, at 1:16 PM, Joe Groff via swift-evolution > wrote: > >> >> On Aug 21, 2017, at 11:23 PM, Jonathan Hull via swift-evolution >> wrote: >> >> I have seen a lot of examples which use both do and beginAsync: >> >>

Re: [swift-evolution] [Concurrency] async/await + actors

> On Aug 20, 2017, at 3:56 PM, Yuta Koshizawa <ko...@koherent.org> wrote: > > 2017-08-21 2:20 GMT+09:00 John McCall via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>>: >> On Aug 19, 2017, at 7:17 PM, Chris Lattner via

Re: [swift-evolution] [Concurrency] async/await + actors

> On Aug 19, 2017, at 7:17 PM, Chris Lattner via swift-evolution > wrote: >> On Aug 19, 2017, at 8:14 AM, Karim Nassar via swift-evolution >> > wrote: >> >> This looks fantastic. Can’t wait (heh) for

Re: [swift-evolution] Fast enums (was: typed throws)

> On Aug 18, 2017, at 8:13 PM, Jonathan Hull wrote: > > It is different though. > > Sure, with a little bit of sugar, it can be used to make something that looks > a bit like union types, but it should avoid the complexity in the type > checker which caused that to be on the

Re: [swift-evolution] typed throws

> On Aug 19, 2017, at 12:25 AM, John McCall via swift-evolution > <swift-evolution@swift.org> wrote: >> On Aug 18, 2017, at 11:43 PM, Mark Lilback <m...@lilback.com >> <mailto:m...@lilback.com>> wrote: >> >>> >>> On Aug 18, 2

Re: [swift-evolution] typed throws

> On Aug 18, 2017, at 11:43 PM, Mark Lilback <m...@lilback.com> wrote: > >> >> On Aug 18, 2017, at 2:27 AM, John McCall via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> Even for non-public code. The only practical merit of typed

Re: [swift-evolution] [Concurrency] async/await + actors

> On Aug 18, 2017, at 3:11 PM, Joe Groff via swift-evolution > wrote: > >> On Aug 18, 2017, at 11:57 AM, Chris Lattner via swift-evolution >> wrote: >> >> I think that awaiting on the result of an actor method ends up being pretty >>

Re: [swift-evolution] typed throws

ir right. If they're doing that, then they can have an async function that does that just as well as they can have a non-async function. However, "async" implying "throws" would undermine them to a significant extent. John. > > Gwendal Roué > > > &g

Re: [swift-evolution] Fast enums (was: typed throws)

> On Aug 18, 2017, at 6:36 AM, Jonathan Hull via swift-evolution > wrote: > The typed throws discussion brought me back to an old thought. > > I would really like to see a new structural type, similar to tuples, which > act as an anonymous enum. These would actually

Re: [swift-evolution] typed throws

> On Aug 18, 2017, at 10:19 AM, Matthew Johnson wrote: > > > > Sent from my iPad > > On Aug 18, 2017, at 1:27 AM, John McCall wrote: > >>> On Aug 18, 2017, at 12:58 AM, Chris Lattner via swift-evolution >>> wrote: >>>

Re: [swift-evolution] typed throws

> On Aug 18, 2017, at 3:28 AM, Charlie Monroe <char...@charliemonroe.net> wrote: >> On Aug 18, 2017, at 8:27 AM, John McCall via swift-evolution >> <swift-evolution@swift.org> wrote: >>> On Aug 18, 2017, at 12:58 AM, Chris Lattner via swift-evolution &

Re: [swift-evolution] typed throws

> On Aug 18, 2017, at 3:24 AM, Tino Heth <2...@gmx.de> wrote: > > >> The only practical merit of typed throws I have ever seen someone >> demonstrate is that it would let them use contextual lookup in a throw or >> catch. People always say "I'll be able to exhaustively switch over my >>

Re: [swift-evolution] typed throws

> On Aug 18, 2017, at 12:58 AM, Chris Lattner via swift-evolution > wrote: > Splitting this off into its own thread: > >> On Aug 17, 2017, at 7:39 PM, Matthew Johnson wrote: >> One related topic that isn’t discussed is type errors. Many third

Re: [swift-evolution] [Accepted] SE-0185 - Synthesizing Equatable and Hashable conformance

> On Aug 16, 2017, at 6:35 PM, Rudolf Adamkovič via swift-evolution > wrote: > > This is fantastic news! Any chance of this landing in Swift 4.x instead of 5? It it likely to be available in 4.1, but not 4.0. John. > > R+ > >> On 17 Aug 2017, at 00:29, Chris

Re: [swift-evolution] [swift-evolution-announce] Swift 5: start your engines

> On Aug 9, 2017, at 8:52 PM, Howard Lovatt via swift-evolution > wrote: > I am not against these changes, of requiring an implementation, but I am a > little nervous. Let me expand. > > I was involved in the Java Coin initiative for community driven changes to >

Re: [swift-evolution] Swift 5: start your engines

> On Aug 9, 2017, at 2:30 AM, Brent Royal-Gordon via swift-evolution > wrote: > >> On Aug 8, 2017, at 3:07 PM, Erica Sadun via swift-evolution >> wrote: >> >> Upfront costs *will* be higher. Not only do you have to believe that a >>

Re: [swift-evolution] [Planning][Request] "constexpr" for Swift 5

> On Aug 6, 2017, at 11:59 PM, Daryle Walker wrote: >> On Aug 1, 2017, at 2:58 PM, John McCall > > wrote: >> >>> >>> On Aug 1, 2017, at 9:53 AM, Daryle Walker >> > wrote: >>> On

Re: [swift-evolution] [Planning][Request] "constexpr" for Swift 5

> On Aug 6, 2017, at 11:15 AM, Karl Wagner <razie...@gmail.com> wrote: > > >> On 4. Aug 2017, at 20:15, John McCall via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >>> >>>

Re: [swift-evolution] [Planning][Request] "constexpr" for Swift 5

> On Aug 4, 2017, at 1:19 PM, Félix Cloutier via swift-evolution > wrote: > > That's not a concern with the `let` case that Robert brought up, since you > can't mutate a `let` array at all. > > The big thing is that unconstrained escape analysis is uncomputable.

Re: [swift-evolution] [Pitch] New Version of Array Proposal

> On Aug 3, 2017, at 12:45 AM, Daryle Walker wrote: >> On Aug 2, 2017, at 4:44 PM, Karl Wagner via swift-evolution >> > wrote: >> >> I’m -1 on adding a fixed-sized Array type. >> >> It goes back to something which I

Re: [swift-evolution] [Planning][Request] "constexpr" for Swift 5

> On Aug 2, 2017, at 6:29 PM, Karl Wagner <razie...@gmail.com> wrote: > > >> On 3. Aug 2017, at 00:21, John McCall <rjmcc...@apple.com >> <mailto:rjmcc...@apple.com>> wrote: >> >> >>> On Aug 2, 2017, at 6:10 PM, John McCall via s

Re: [swift-evolution] [Planning][Request] "constexpr" for Swift 5

> On Aug 2, 2017, at 5:56 PM, Karl Wagner <razie...@gmail.com> wrote: >> On 31. Jul 2017, at 21:09, John McCall via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >>> On Jul 31, 2017, at 3:15 A

Re: [swift-evolution] [Planning][Request] "constexpr" for Swift 5

> On Aug 2, 2017, at 12:17 PM, Félix Cloutier wrote: > `[Int x N]` solves all of the problems that I mentioned, and I'm happy with > that syntax. In fact, I'm championing its merits versus an approach that > doesn't include the number of elements. :) > > Unless I got

Re: [swift-evolution] [Planning][Request] "constexpr" for Swift 5

> On Aug 2, 2017, at 11:44 AM, Félix Cloutier via swift-evolution > wrote: > > >> Le 31 juil. 2017 à 18:54, Xiaodi Wu > > a écrit : >> It doesn't allow you to specify the size of the array, it's just a promise >>

Re: [swift-evolution] [Pitch] New Version of Array Proposal

> On Aug 1, 2017, at 5:49 PM, David Sweeris via swift-evolution > wrote: >> On Aug 1, 2017, at 10:54 AM, Daryle Walker via swift-evolution >> wrote: >> >> A tuple can have its members initialized in piecemeal and still satisfy >>

Re: [swift-evolution] [Planning][Request] "constexpr" for Swift 5

m>> wrote: >>>> >>>> >>>>> On Jul 31, 2017, at 10:09 PM, John McCall <rjmcc...@apple.com >>>>> <mailto:rjmcc...@apple.com>> wrote: >>>>> >>>>>> On Jul 31, 2017, at 3:15 AM, Gor Gyolchanyan

Re: [swift-evolution] [Planning][Request] "constexpr" for Swift 5

ype generic parameters? >> >> Are you under the impression that Swift does not, today, instantiate generic >> types at runtime? >> >> A lot of this entire thread seems to be premised on really weird, incorrect >> assumptions about the Swift compilation model. >&

Re: [swift-evolution] [Planning][Request] "constexpr" for Swift 5

t;> >>>>> On Jul 31, 2017, at 3:15 AM, Gor Gyolchanyan >>>>> <gor.f.gyolchan...@icloud.com <mailto:gor.f.gyolchan...@icloud.com>> >>>>> wrote: >>>>>> On Jul 31, 2017, at 7:10 AM, John McCall via swift-evolution >>

Re: [swift-evolution] [Planning][Request] "constexpr" for Swift 5

at 3:15 AM, Gor Gyolchanyan <gor.f.gyolchan...@icloud.com >>> <mailto:gor.f.gyolchan...@icloud.com>> wrote: >>>> On Jul 31, 2017, at 7:10 AM, John McCall via swift-evolution >>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrot

Re: [swift-evolution] [Planning][Request] "constexpr" for Swift 5

> On Jul 31, 2017, at 3:15 AM, Gor Gyolchanyan <gor.f.gyolchan...@icloud.com> > wrote: >> On Jul 31, 2017, at 7:10 AM, John McCall via swift-evolution >> <swift-evolution@swift.org> wrote: >> >>> On Jul 30, 2017, at 11:43 PM, Daryle Walker <dary..

Re: [swift-evolution] [Planning][Request] "constexpr" for Swift 5

;> Le 30 juil. 2017 à 21:10, John McCall via swift-evolution >> <swift-evolution@swift.org> a écrit : >> >>> On Jul 30, 2017, at 11:43 PM, Daryle Walker <dary...@mac.com> wrote: >>> The parameters for a fixed-size array type determine the type's &g

Re: [swift-evolution] [Planning][Request] "constexpr" for Swift 5

> On Jul 30, 2017, at 11:43 PM, Daryle Walker wrote: > The parameters for a fixed-size array type determine the type's size/stride, > so how could the bounds not be needed during compile-time? The compiler can't > layout objects otherwise. Swift is not C; it is perfectly

Re: [swift-evolution] Why couldn't a class call any of its superclass' initializers?

> On Jul 26, 2017, at 12:36 AM, Daryle Walker via swift-evolution > wrote: > [Sorry if this's been discussed before.] > > As long as the superclass sub-object gets initialized, it shouldn't matter if > the initializer was designated or convenience. Is there some

Re: [swift-evolution] Pitch: Wrap calls to NSFileHandle and NSData in autorelease pools

> On Jul 14, 2017, at 4:43 PM, Charles Srstka wrote: > >> On Jul 14, 2017, at 3:40 PM, John McCall > > wrote: >> >> Would you mind just filing a bug with a reduced test case? >> >> John. > > Radar or bugs.swift.org

Re: [swift-evolution] Pitch: Wrap calls to NSFileHandle and NSData in autorelease pools

> On Jul 14, 2017, at 4:15 PM, Charles Srstka wrote: > >> On Jul 14, 2017, at 2:35 PM, John McCall > > wrote: >> >>> On Jul 14, 2017, at 1:12 PM, Charles Srstka via swift-evolution >>>

Re: [swift-evolution] Pitch: Wrap calls to NSFileHandle and NSData in autorelease pools

> On Jul 14, 2017, at 4:31 PM, Charles Srstka wrote: >> On Jul 14, 2017, at 3:24 PM, John McCall > > wrote: >> >> We should absolutely not need to do the later autoreleases. We have logic >> to autorelease objects when

Re: [swift-evolution] Pitch: Wrap calls to NSFileHandle and NSData in autorelease pools

> On Jul 14, 2017, at 1:12 PM, Charles Srstka via swift-evolution > wrote: > MOTIVATION: > > Meet Bob. Bob is a developer with mostly C++ and Java experience, but who has > been learning Swift. Bob needs to write an app to parse some proprietary > binary data format

Re: [swift-evolution] [Proposal] Introduces endianness specific type

> On Jul 9, 2017, at 6:57 PM, Robert Bennett wrote: > Just a question: how would/does allowing the reordering of fields affect the > correctness and performance of the (de)serialization API added in Swift 4? The design of that is definitely proof against changes to the

Re: [swift-evolution] [Proposal] Introduces endianness specific type

> On Jul 9, 2017, at 6:14 PM, Jens Persson wrote: > > Thanks for that clarification John McCall. > My code is using a lot of generic structs (in which memory layout is > important) though, an example would be: > struct Vector4 : Vector { > typealias Index = VectorIndex4

Re: [swift-evolution] [Proposal] Introduces endianness specific type

> On Jul 9, 2017, at 4:49 PM, Jens Persson via swift-evolution > wrote: > > Sorry for making so much off topic noise in this thread, but I made a mistake > regarding the Metal tutorial: > Looking more carefully I see now that they rebuild a vertedData: [Float] from

[swift-evolution] [Accepted] SE-0180: String Index Overhaul

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0180-string-index-overhaul.md The second review of “SE-0180: String Index Overhaul" ran from June 22nd – 28th, 2017.

Re: [swift-evolution] [Pitch] Object aliases

> On Jun 30, 2017, at 4:55 AM, Daryle Walker wrote: >> On Jun 30, 2017, at 1:11 AM, John McCall > > wrote: >> >>> >>> On Jun 23, 2017, at 3:28 AM, Daryle Walker via swift-evolution >>>

Re: [swift-evolution] [Pitch] Object aliases

> On Jun 23, 2017, at 3:28 AM, Daryle Walker via swift-evolution > wrote: > > I started a thread earlier this week about strong type-aliases and object > aliases. Here’s a fuller proposal on object aliases. > > Feature name > Proposal: SE- > Authors: Daryle

Re: [swift-evolution] floating point numbers implicit conversion

> On Jun 19, 2017, at 5:43 PM, David Sweeris <daveswee...@mac.com> wrote: > Sent from my iPhone > On Jun 19, 2017, at 13:44, John McCall via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > >>> On Jun 19,

Re: [swift-evolution] floating point numbers implicit conversion

> On Jun 19, 2017, at 1:58 PM, Stephen Canon via swift-evolution > wrote: >> On Jun 19, 2017, at 11:46 AM, Ted F.A. van Gaalen via swift-evolution >> > wrote: >> >> var result: Float = 0.0 >> result = float

Re: [swift-evolution] [Proposal] Change Void meaning

> On Jun 14, 2017, at 4:45 AM, Jérémie Girault > wrote: > @john, the proposal is the fruit of my imagination and the goal was to > discuss about it. > I’m vastly open to change it with the help of anyone if it can be implemented > in a simple way and leads to better

Re: [swift-evolution] [swift-dev] RFC: bridging peephole for "as" casts

> On Jun 14, 2017, at 2:24 AM, David Hart wrote: > Very good description. It's always worth re-explaining terms like bridged > conversion to make sure every body is on the same page. But concerning the > rules at the end, I’m not quite sure I understood them all. Please

Re: [swift-evolution] [Proposal] Change Void meaning

ap(_ a: inout T, _ b: inout T) >>>> >>>> What would happen with that? >>>> Will inout arguments be an exception to the rule of Void getting a default >>>> value, and if so, what would the effects of that be? >>>> Or would it somehow be al

Re: [swift-evolution] [Proposal] Change Void meaning

t; >> What would happen with that? >> Will inout arguments be an exception to the rule of Void getting a default >> value, and if so, what would the effects of that be? >> Or would it somehow be allowed to call swap()? >> Or is there a third alternative? >> /Jens >

Re: [swift-evolution] [Proposal] Change Void meaning

> On Jun 13, 2017, at 4:41 AM, Xiaodi Wu wrote: > > On Tue, Jun 13, 2017 at 3:06 AM, John McCall > wrote: >> On Jun 13, 2017, at 3:30 AM, Jérémie Girault > >

Re: [swift-evolution] [Proposal] Change Void meaning

> On Jun 13, 2017, at 3:30 AM, Jérémie Girault > wrote: > > Exactly, > The reflexion behind it is: > > - Let's understand that 0110 and other tuple SE are important for the > compiler, we do not want them to rollback > - However we have number of regressions for

Re: [swift-evolution] Swift phases and mis-timed proposals

> On Jun 13, 2017, at 3:22 AM, David Sweeris <daveswee...@mac.com> wrote: >> On Jun 13, 2017, at 12:18 AM, John McCall via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >>> On Jun 13, 2017, at

Re: [swift-evolution] [Proposal] Change Void meaning

n fact be different. >>>>> >>>>> I don’t think so. But different from `func foo(Unit)` ? Yes ! >>>>> >>>>> >>>>> It sounds like your quarrel is with the name of the typealias. I don’t >>>>> see how that solves an

Re: [swift-evolution] Swift phases and mis-timed proposals

> On Jun 13, 2017, at 1:08 AM, Jacob Bandes-Storch via swift-evolution > wrote: > On Mon, Jun 12, 2017 at 9:31 PM, Paul Cantrell via swift-evolution > > wrote: > I support everything Jon wrote. > > +1

Re: [swift-evolution] [Proposal] Change Void meaning

syntax for tuple argument destructuring? I.e. > allowed: .filter {(friend: (name: String, age: Int)) in friend.age >= 18 } > proposed: .filter {(friend: (name, age)) in friend.age >= 18 } > > * And the same for passing function with no parameters if function with > single Void parameter is

Re: [swift-evolution] History and future of Swift's parentheses

> On Jun 12, 2017, at 3:13 PM, Jens Persson wrote: > On Mon, Jun 12, 2017 at 8:52 PM, John McCall > wrote: > > We really do want to tie most of these features specifically to function > calls. > > > I'm not sure if I

  1   2   3   4   5   >