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

> On Jan 12, 2018, at 6:31 PM, Jonathan Hull via swift-evolution > wrote: > > I’m definitely in the error camp, but I will go along with a warning if > everyone feels that is better. I see advantages both ways. The fact that the error approach generalizes much cleaner is definitely a plus.

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

> On Jan 12, 2018, at 2:00 PM, John McCall via swift-evolution > wrote: > > >> On Jan 12, 2018, at 12:53 PM, BJ Homer via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> I agree that this behavior is annoying. However, wouldn’t it be >> source-breaking to change this now?

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

Sent from my iPad > On Jan 12, 2018, at 12:25 PM, Jordan Rose via swift-evolution > wrote: > > > >> On Jan 11, 2018, at 23:30, Chris Lattner wrote: >> >> >>> On Jan 11, 2018, at 11:15 PM, Jean-Daniel via swift-evolution >>> wrote: >>> >>> A question about the new #unknown behavior. Is

Re: [swift-evolution] [Pitch] Generalized supertype constraints

> On Jan 10, 2018, at 2:19 PM, Rex Fenley wrote: > > Have you found anyone else to help on this one? I would like to dive in > myself but I don't have any experience with the compiler and not sure about > the size of the workload here. Hi Rex, thank you for offering to help! I have not found

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0194: Derived Collection of Enum Cases

> What is your evaluation of the proposal? +1. I have written plenty of enums with the `allValues` property. It will be nice to have this synthesized. I do think a small clarification or revision is warranted, however. I would like to see a rationale stated for choosing the `Collection` requ

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

Sent from my iPad > On Jan 3, 2018, at 12:20 PM, Dave DeLong wrote: > > > >>> On Jan 3, 2018, at 11:09 AM, Matthew Johnson wrote: >>> >>> On Jan 3, 2018, at 12:02 PM, Dave DeLong wrote: On Jan 3, 2018, at 10:58 AM, Kevin Nattinger wrote: >>> [...] >

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

> On Jan 3, 2018, at 12:02 PM, Dave DeLong wrote: > > > >> On Jan 3, 2018, at 10:58 AM, Kevin Nattinger > > wrote: >> > [...] > 2️⃣ If the enum is NOT decorated with @frozen, then I, as an app > author, have to account for the possibility that the mo

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

> On Jan 3, 2018, at 11:49 AM, Dave DeLong wrote: > > > >> On Jan 3, 2018, at 10:36 AM, Matthew Johnson > > wrote: >> >> >>> On Jan 3, 2018, at 11:07 AM, Dave DeLong via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> >>> IMO this is still t

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

> On Jan 3, 2018, at 11:47 AM, BJ Homer wrote: > > > >> On Jan 3, 2018, at 10:36 AM, Matthew Johnson via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> This does not help people who need to write a switch statement over an enum

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

> On Jan 3, 2018, at 11:07 AM, Dave DeLong via swift-evolution > wrote: > > IMO this is still too large of a hammer for this problem. > > This whole “unexpected case” thing is only a problem when you’re linking > libraries that are external to/shipped independently of your app. Right now, >

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

> On Jan 2, 2018, at 8:45 PM, Xiaodi Wu via swift-evolution > wrote: > > On Tue, Jan 2, 2018 at 8:07 PM, Jordan Rose via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > [Proposal: > https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md > >

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

> On Jan 2, 2018, at 8:07 PM, Jordan Rose via swift-evolution > wrote: > > [Proposal: > https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md > > ] > > Whew! Th

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

; >> On Tue, Jan 2, 2018 at 9:38 AM, Matthew Johnson via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> >> Sent from my iPad >> >> On Jan 1, 2018, at 11:47 PM, Chris Lattner > <mailto:clatt...@nondot.org>> wrote

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

> On Jan 2, 2018, at 3:41 PM, Xiaodi Wu wrote: > > On Tue, Jan 2, 2018 at 3:27 PM, Kevin Nattinger > wrote: > [...] > >>> in what other circumstances do we insist that the compiler inform the end >>> user about future additions to the API at compile time? >> >> Th

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

Sent from my iPad > On Jan 2, 2018, at 12:48 PM, Xiaodi Wu wrote: > >> On Tue, Jan 2, 2018 at 9:38 AM, Matthew Johnson via swift-evolution >> wrote: >> >> >> Sent from my iPad >> >> On Jan 1, 2018, at 11:47 PM, Chris Lattner wrote: >&g

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

Sent from my iPad >> On Jan 1, 2018, at 11:47 PM, Chris Lattner wrote: >> >> On Dec 31, 2017, at 12:14 PM, Matthew Johnson via swift-evolution >> wrote: >> >> I agree that we need a solution to the problem described. I also agree that >> non-exha

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

I have been busy over the holidays and have been considering the arguments in this thread so my review is late in coming. > What is your evaluation of the proposal? > I agree that we need a solution to the problem described. I also agree that non-exhaustive is most in keeping with the overall d

Re: [swift-evolution] [swift-dev] Re-pitch: Deriving collections of enum cases

This looks really nice. Thank you for doing the legwork of researching previous discussions and writing up a detailed proposal! The motivation discusses the common use case of using an enum in a data source implementation which requires 0-based Int indices. However, the proposed solution as-w

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

> On Dec 21, 2017, at 2:17 PM, John McCall wrote: > > >> On Dec 21, 2017, at 3:10 PM, Matthew Johnson > > wrote: >> >> >>> On Dec 21, 2017, at 2:06 PM, John McCall >> > wrote: >>> >>> On Dec 21, 2017, at 2:41 PM, Matthew Johnson

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

> On Dec 21, 2017, at 2:06 PM, John McCall wrote: > > >> On Dec 21, 2017, at 2:41 PM, Matthew Johnson > > wrote: >> >> >>> On Dec 21, 2017, at 1:26 PM, John McCall via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> On Dec 21, 2017

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

> On Dec 21, 2017, at 1:26 PM, John McCall via swift-evolution > wrote: > >> >> On Dec 21, 2017, at 2:03 PM, Jordan Rose via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> >> >>> On Dec 20, 2017, at 12:35, Karl Wagner >> > wrote: >>> >>> >>>

Re: [swift-evolution] Refining SE-0185: Should providing a custom == suppress the default hashValue?

+1. I think there is a reasonable general principle at work here: the semantics of the implementation of a refining protocol depend upon the semantics of the implementation of a refined protocol. For this reason the compiler should not synthesize an implementation for a refining protocol unles

Re: [swift-evolution] Optional Argument Chaining

Sent from my iPad On Dec 13, 2017, at 11:13 PM, Stephen Celis wrote: >> On Dec 13, 2017, at 9:53 PM, Erica Sadun wrote: >> >> Chris L had a beautiful solution for an "Unwrappable" protocol that allowed >> all of the optional sugar to be extended to any type that had a biased >> `Wrapped` i

Re: [swift-evolution] Optional Argument Chaining

It’s worth mentioning that the problem this thread is discussing can be generalized to idioms / applicative. The specific case here is for Optional but many other types could benefit from an elegant syntactic solution to this problem. It might be worth exploring a more general solution. Here’

Re: [swift-evolution] [RFC] Associated type inference

Sent from my iPad > On Dec 7, 2017, at 5:27 PM, Douglas Gregor via swift-evolution > wrote: > > > >> On Dec 2, 2017, at 9:23 PM, Dave Abrahams wrote: >> >> >>> On Nov 30, 2017, at 2:28 PM, Douglas Gregor via swift-evolution >>> wrote: >> >>> What’s a Good Solution Look Like? >>> Our c

Re: [swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

> On Dec 4, 2017, at 6:45 AM, Nick Keets wrote: > > > > On Sun, Dec 3, 2017 at 10:16 PM, Matthew Johnson via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > > Some people are big fans of dynamic behavior and this feature will make it > much e

Re: [swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

> On Dec 3, 2017, at 5:40 PM, Chris Lattner wrote: > > > >> On Dec 3, 2017, at 3:39 PM, Matthew Johnson > > wrote: >> If that's the concern, then it would be pretty straightforward to restrict dynamic protocols for stdlib internal use only and expose

Re: [swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

> On Dec 3, 2017, at 5:38 PM, Chris Lattner wrote: > > > >> On Dec 3, 2017, at 3:34 PM, Matthew Johnson > > wrote: >> >>> >>> On Dec 3, 2017, at 5:14 PM, Chris Lattner >> > wrote: >>> >>> On Dec 3, 2017, at 2:44 PM, Xiaodi Wu

Re: [swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

> On Dec 3, 2017, at 5:14 PM, Chris Lattner wrote: > > >> On Dec 3, 2017, at 2:44 PM, Xiaodi Wu > > wrote: >> >>> >>> and you don’t realize that PyVal’s are involved. However, if you are >>> actively writing the code, you have access to code completion and other

Re: [swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

> On Dec 3, 2017, at 5:14 PM, Chris Lattner wrote: > > >> On Dec 3, 2017, at 2:44 PM, Xiaodi Wu > > wrote: >> >>> >>> and you don’t realize that PyVal’s are involved. However, if you are >>> actively writing the code, you have access to code completion and other

Re: [swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

> On Dec 3, 2017, at 11:36 AM, Chris Lattner wrote: > > On Dec 2, 2017, at 7:11 PM, Matthew Johnson > wrote: >>> >>> This does not improve clarity of code, it merely serves to obfuscate logic. >>> It is immediately apparent from the APIs being used, the API sty

Re: [swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

Sent from my iPad > On Dec 3, 2017, at 10:40 AM, David Hart wrote: > > > >> On 3 Dec 2017, at 04:11, Matthew Johnson via swift-evolution >> wrote: >> >> >> >> Sent from my iPad >> >>> On Dec 2, 2017, at 7:40 PM, Chr

Re: [swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

Sent from my iPad > On Dec 2, 2017, at 7:40 PM, Chris Lattner wrote: > > On Dec 2, 2017, at 2:13 PM, Matthew Johnson wrote: >>> For all those reasons, we really do need something like AnyObject dispatch >>> if we care about working with dynamically typed languages. The design I’m >>> sugge

Re: [swift-evolution] [RFC] Associated type inference

Sent from my iPad > On Dec 2, 2017, at 4:40 PM, Douglas Gregor wrote: > > > > Sent from my iPhone > >> On Dec 2, 2017, at 1:37 PM, Matthew Johnson wrote: >> >> >>> On Nov 30, 2017, at 6:28 PM, Douglas Gregor via swift-evolution >>> wrote: >>> >>> Hello Swift community, >>> >>> Associ

Re: [swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

> On Dec 2, 2017, at 2:44 PM, Chris Lattner wrote: > > On Dec 1, 2017, at 5:50 PM, Matthew Johnson > wrote: This design introduces a significant hole in the type system which is contrary to the spirit of Swift. >>> >>> There is no “hole” in the type sy

Re: [swift-evolution] [RFC] Associated type inference

> On Nov 30, 2017, at 6:28 PM, Douglas Gregor via swift-evolution > wrote: > > Hello Swift community, > > Associated type inference, which is the process by which the Swift compiler > attempts to infer typealiases to satisfy associated-type requirements based > on other requirements, has cau

Re: [swift-evolution] [Pitch] Generalized supertype constraints

This thread received very light, but positive feedback. I would really like to see this feature added and am willing to draft and official proposal but am not able to implement it. If anyone is interested in collaborating just let me know. > On Nov 24, 2017, at 5:03 PM, Matthew Johnson

Re: [swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

> On Dec 1, 2017, at 12:23 AM, Chris Lattner wrote: > >> On Nov 30, 2017, at 6:15 AM, Matthew Johnson wrote: >>> >>> I think better interoperability with Python (and other OO languages in >>> widespread use) is a good goal, and I agree that the implementation of the >>> feature described is

Re: [swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

> On Nov 30, 2017, at 3:48 PM, Paul Cantrell via swift-evolution > wrote: > > > >> On Nov 30, 2017, at 3:40 PM, Douglas Gregor via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> >> >>> On Nov 30, 2017, at 1:01 PM, Zach Wolfe >> > wrot

Re: [swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

Sent from my iPad > On Nov 30, 2017, at 2:24 AM, Douglas Gregor via swift-evolution > wrote: > > > >> On Nov 26, 2017, at 10:04 PM, Chris Lattner via swift-evolution >> wrote: >> >> I’d like to formally propose the inclusion of user-defined dynamic member >> lookup types. >> >> Here is

Re: [swift-evolution] [Pre-pitch] Conditional default arguments

> On Nov 28, 2017, at 4:11 PM, Slava Pestov wrote: > > > >> On Nov 28, 2017, at 1:35 PM, Matthew Johnson > > wrote: >> * the compiler doesn’t have to reason about an overload set which might improve build times, etc >>> >>> They’re effectively equiva

Re: [swift-evolution] [Pre-pitch] Conditional default arguments

> On Nov 28, 2017, at 3:28 PM, Slava Pestov wrote: > > > >> On Nov 28, 2017, at 1:25 PM, Matthew Johnson > > wrote: >> >> >>> On Nov 28, 2017, at 3:18 PM, Slava Pestov >> > wrote: >>> >>> >>> On Nov 28, 2017, at 8:44 AM, Matthe

Re: [swift-evolution] [Pre-pitch] Conditional default arguments

> On Nov 28, 2017, at 3:18 PM, Slava Pestov wrote: > > > >> On Nov 28, 2017, at 8:44 AM, Matthew Johnson > > wrote: >> >> func makeResource( >> with configuration: Configuration = () where Configuration == Void, >> actionHandler: @escaping (Action) -> V

Re: [swift-evolution] [Pre-pitch] Conditional default arguments

> On Nov 28, 2017, at 11:40 AM, Tony Allevato wrote: > > > > On Tue, Nov 28, 2017 at 9:16 AM Matthew Johnson > wrote: >> On Nov 28, 2017, at 11:01 AM, Tony Allevato > > wrote: >> >> >> >> On Tue, Nov 28, 2017 at 8:45 AM Matthew

Re: [swift-evolution] [Pre-pitch] Conditional default arguments

> On Nov 28, 2017, at 11:01 AM, Tony Allevato wrote: > > > > On Tue, Nov 28, 2017 at 8:45 AM Matthew Johnson > wrote: >> On Nov 28, 2017, at 10:06 AM, Tony Allevato > > wrote: >> >> >> >> On Mon, Nov 27, 2017 at 10:32 PM Slava

Re: [swift-evolution] [Pre-pitch] Conditional default arguments

> On Nov 28, 2017, at 10:06 AM, Tony Allevato wrote: > > > > On Mon, Nov 27, 2017 at 10:32 PM Slava Pestov > wrote: > Hi Tony, > > So if my understanding is correct, the basic proposal is the following: > > func id(t: T ?= T.defaultValue) { return t } > > extensio

Re: [swift-evolution] [Pre-pitch] Conditional default arguments

> On Nov 28, 2017, at 12:34 AM, Slava Pestov wrote: > > > >> On Nov 27, 2017, at 3:38 PM, Matthew Johnson via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> You are effectively proposing that in this very narrow case we perfor

Re: [swift-evolution] [Pre-pitch] Conditional default arguments

ression that references static >>>> (but not instance) vars of the enclosing type, as well as anything else >>>> that’s visible from that expression’s scope. Should people do this? >>>> Probably not, for the reasons that you described. >>>> >>>> But the

Re: [swift-evolution] [Pre-pitch] Conditional default arguments

oose different default factories (or choose >>> none without error) based on the static types of the generic arguments that >>> are bound at a particular call site. >>> >>> >>> >>> I think I prefer Xiaodi’s suggestion for that reason. His app

Re: [swift-evolution] [Pre-pitch] Conditional default arguments

the same parameter as long as the >> constraints are not allowed to overlap (overlapping constraints would result >> in ambiguity similar to ambiguous overload resolution) or an explicit >> argument is required if they do. >> >>> >>> >>> >&

Re: [swift-evolution] [Pre-pitch] Conditional default arguments

>> >> On Mon, Nov 27, 2017 at 11:12 AM Matthew Johnson via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >>> On Nov 27, 2017, at 12:50 PM, Douglas Gregor >> <mailto:dgre...@apple.com>> wrote: >>> >>> >>

Re: [swift-evolution] [Pre-pitch] Conditional default arguments

> On Nov 27, 2017, at 1:24 PM, Tony Allevato wrote: > > > > On Mon, Nov 27, 2017 at 11:12 AM Matthew Johnson via swift-evolution > mailto:swift-evolution@swift.org>> wrote: >> On Nov 27, 2017, at 12:50 PM, Douglas Gregor > <mailto:dgre...@apple.com>&

Re: [swift-evolution] [Pre-pitch] Conditional default arguments

> On Nov 27, 2017, at 12:50 PM, Douglas Gregor wrote: > > > >> On Nov 24, 2017, at 3:11 PM, Matthew Johnson via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> As mentioned in my prior message, I currently have a PR open t

Re: [swift-evolution] [Pre-pitch] Conditional default arguments

n) -> Void) -> R > @overload(R.Action == Never) func makeResource(with configuration: > R.Configuration) -> R > { > // create a resource using the provided configuration > // connect the action handler > // return the resource > } > } > ``` &g

[swift-evolution] [Pre-pitch] Conditional default arguments

As mentioned in my prior message, I currently have a PR open to update the generics manifesto (https://github.com/apple/swift/pull/13012 ). I removed one topic from that update at Doug Gregor’s request that it be discussed on the list first. The ide

[swift-evolution] [Pitch] Generalized supertype constraints

One of the most frequent frustrations I encounter when writing generic code in Swift is the requirement that supertype constraints be concrete. When I mentioned this on Twitter (https://twitter.com/anandabits/status/929958479598534656 )

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

Seems like a no-brainer to me. If there has been any argument against making this change I am really curious to know what it is. I’m super excited that this might make it into 4.1. Woohoo!!! > On Nov 22, 2017, at 12:51 AM, Douglas Gregor via swift-evolution > wrote: > > Hi all, > > We’re

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

Sent from my iPhone > On Nov 14, 2017, at 6:56 PM, Howard Lovatt via swift-evolution > wrote: > > Having read all the arguments for what to add to local functions it still > strikes me as a poor use of engineering resources to fix them (though I do > agree they have problems). A better use

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

Sent from my iPad > On Nov 11, 2017, at 5:27 PM, Chris Lattner wrote: > > Ok, which differences? > > -Chris > >> On Nov 11, 2017, at 2:19 PM, Matthew Johnson via swift-evolution >> wrote: >> >> >> >> Sent from my iPad >

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

Sent from my iPad > On Nov 11, 2017, at 11:40 AM, Chris Lattner wrote: > > On Nov 10, 2017, at 6:10 PM, Matthew Johnson via swift-evolution > wrote: >>>> On Nov 10, 2017, at 11:25 AM, Matthew Johnson via swift-evolution >>>> wrote: >>>> >

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

Sent from my iPad > On Nov 10, 2017, at 7:41 PM, Chris Lattner wrote: > > >> On Nov 10, 2017, at 11:25 AM, Matthew Johnson via swift-evolution >> wrote: >> >>>> >>>> People have reasonably asked for the ability to make their own >&

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

> On Nov 10, 2017, at 1:19 PM, Chris Lattner via swift-evolution > wrote: > >> On Nov 10, 2017, at 10:51 AM, Joe Groff via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >>> Since we also lack the more obvious static "Callable" protocol idea to give even well-typed ca

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

Sent from my iPad > On Nov 10, 2017, at 12:51 PM, Joe Groff via swift-evolution > wrote: > > > >> On Nov 10, 2017, at 10:41 AM, Chris Lattner wrote: >> >> On Nov 10, 2017, at 10:03 AM, Joe Groff wrote: >>> >>> I don't like the idea of some calls having wildly different semantics from >

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-188 Make stdlib index types Hashable

Sent from my iPad > On Nov 9, 2017, at 6:29 AM, Xiaodi Wu via swift-evolution > wrote: > > >> On Thu, Nov 9, 2017 at 05:28 Brent Royal-Gordon via swift-evolution >> wrote: >> > >> > https://github.com/apple/swift-evolution/blob/master/proposals/0188-stdlib-index-types-hashable.md >>

Re: [swift-evolution] Pitch: Remove default initialization of optional bindings

> On Nov 6, 2017, at 4:33 PM, Slava Pestov via swift-evolution > wrote: > > Hi all, > > Right now, the following two declarations are equivalent: > > struct S { > var x: Int? > } > > struct S { > var x: Int? = nil > } > > That is, mutable bindings of sugared optional type (but not Optiona

Re: [swift-evolution] Adding Result to the Standard Library

I have been writing code in a style that uses explicit effect handling lately. In this style of code, a request describing an async task is returned from a function and later interpreted by a library. When the task completes the library passes the result to completion handler that is part of t

Re: [swift-evolution] Pitch: Member lookup on String should not find members of NSString

Sent from my iPad > On Oct 24, 2017, at 5:55 PM, Slava Pestov via swift-evolution > wrote: > > I think to maintain source compatibility, the old behavior would be preserved > until/if we remove -swift-version 4 mode. By deprecating it though, we won’t > have to devote as much time to mainta

Re: [swift-evolution] [draft] Introduce Sequence.filteredMap(_:)

> On Oct 24, 2017, at 1:57 AM, David Hart via swift-evolution > wrote: > > I also cast my vote for filterMap. It’s concise, understandable and is kind > of a term of art also. +1. This seems like the best option to me. > >> On 24 Oct 2017, at 02:56, BJ Homer via swift-evolution >> mailto:

Re: [swift-evolution] Fix "private extension" (was "Public Access Modifier Respected in Type Definition")

Sent from my iPad > On Oct 2, 2017, at 7:33 PM, Jordan Rose via swift-evolution > wrote: > > > >> On Oct 2, 2017, at 03:25, Vladimir.S via swift-evolution >> wrote: >> >> On 01.10.2017 1:18, Chris Lattner wrote: On Sep 29, 2017, at 10:42 AM, Xiaodi Wu via swift-evolution wrot

Re: [swift-evolution] Enums and Source Compatibility

Sent from my iPad > On Sep 17, 2017, at 5:02 PM, Jonathan Hull wrote: > > >> On Sep 17, 2017, at 7:55 AM, Matthew Johnson wrote: >> >> >> >> Sent from my iPad >> >>> On Sep 17, 2017, at 3:37 AM, Jonathan Hull via swift-evolution >>> wrote: >>> >>> I run into use cases like this all th

Re: [swift-evolution] Enums and Source Compatibility

Sent from my iPad > On Sep 17, 2017, at 3:37 AM, Jonathan Hull via swift-evolution > wrote: > > I run into use cases like this all the time… > > I think I would prefer to see those concrete cases in a subtype though: > > enum DrinkSize { > case small > case

Re: [swift-evolution] [Pitch] Synthesized static enum property to iterate over cases

Sent from my iPad > On Sep 9, 2017, at 2:07 PM, Tony Allevato wrote: > > > >> On Fri, Sep 8, 2017 at 5:14 PM Xiaodi Wu wrote: >>> On Fri, Sep 8, 2017 at 4:08 PM, Matthew Johnson via swift-evolution >>> wrote: >> >>> >

Re: [swift-evolution] [Pitch] Synthesized static enum property to iterate over cases

#x27;s terminology, by definition a nonexhaustive cannot provide a complete list of all values. > > TJ > >> On Sep 9, 2017, at 15:23, Matthew Johnson via swift-evolution >> wrote: >> >> >> >> Sent from my iPad >> >>> On Sep 9, 2017

Re: [swift-evolution] [Pitch] Synthesized static enum property to iterate over cases

Sent from my iPad > On Sep 9, 2017, at 7:33 AM, Brent Royal-Gordon wrote: > >> On Sep 8, 2017, at 5:14 PM, Xiaodi Wu via swift-evolution >> wrote: >> >> Here, people just want an array of all cases. Give them an array of all >> cases. When it's not possible (i.e., in the case of cases with

Re: [swift-evolution] [SE-0155][Discuss] The role of labels in enum case patterns

@gmail.com>> wrote: >>> >>>> >>>> On Sep 4, 2017, at 11:35 AM, Matthew Johnson via swift-evolution >>>> mailto:swift-evolution@swift.org>> wrote: >>>> >>>> >>>>> On Sep 4, 2017, at 11:47 AM, T.J. Usiyan

Re: [swift-evolution] [Pitch] Synthesized static enum property to iterate over cases

> On Sep 8, 2017, at 12:05 PM, Tony Allevato wrote: > > > > On Fri, Sep 8, 2017 at 9:44 AM Matthew Johnson > wrote: >> On Sep 8, 2017, at 11:32 AM, Tony Allevato > > wrote: >> >> >> >> On Fri, Sep 8, 2017 at 8:35 AM Matthew Joh

Re: [swift-evolution] [Proposal] Random Unification

> On Sep 8, 2017, at 2:30 PM, Ben Cohen via swift-evolution > wrote: > > Hi Alejandro, > > I’m really happy to see someone pick this up. We had suggested some kind of > random support could be a goal for addition to the standard library in Swift > 4 phase 2 but didn’t manage it, so I definit

Re: [swift-evolution] [SE-0155][Discuss] The role of labels in enum case patterns

> On Sep 8, 2017, at 2:17 PM, Robert Widmann wrote: > >> >> On Sep 4, 2017, at 11:35 AM, Matthew Johnson via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> >>> On Sep 4, 2017, at 11:47 AM, T.J. Usiyan >> <mailto

Re: [swift-evolution] [Pitch] Synthesized static enum property to iterate over cases

> On Sep 8, 2017, at 11:32 AM, Tony Allevato wrote: > > > > On Fri, Sep 8, 2017 at 8:35 AM Matthew Johnson > wrote: >> On Sep 8, 2017, at 9:53 AM, Tony Allevato via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> Thanks for bringing this up,

Re: [swift-evolution] [Pitch] Synthesized static enum property to iterate over cases

> On Sep 8, 2017, at 9:53 AM, Tony Allevato via swift-evolution > wrote: > > Thanks for bringing this up, Logan! It's something I've been thinking about a > lot lately after a conversation with some colleagues outside of this > community. Some of my thoughts: > > AFAIK, there are two major u

Re: [swift-evolution] [Proposal] Explicit Synthetic Behaviour

rts of the concrete type. It sounds > like this discussion is trying to protect against a hypothetical problem that > hasn't happened yet and may not happen; it would be helpful to show some > motivating real-world cases where this is indeed a severe problem. >> On Thu, Sep 7, 201

Re: [swift-evolution] [Proposal] Explicit Synthetic Behaviour

Sent from my iPad > On Sep 7, 2017, at 7:07 AM, Gwendal Roué via swift-evolution > wrote: > > Hello, > > I'm interested in this debate because I've been bitten by automatic synthesis > recently. > > I'm reading your discussion, but I don't have a strong opinion. I only have > an anecdote:

Re: [swift-evolution] Enums and Source Compatibility

Hi Jordan, The proposal looks very reasonable to me. I don’t have too strong an opinion on this topic, but it occurred to me that your discussion of `future` left out one possible design approach. We could restrict code in the `future` clause to be `break` or `fatalError()`. One of these is

Re: [swift-evolution] [SE-0155][Discuss] The role of labels in enum case patterns

> On Sep 5, 2017, at 3:07 AM, gs. via swift-evolution > wrote: > > > This becomes false in exactly the situation that you described where there > are two projections with similar structure, no? Labels would remove ambiguity > here. > TJ That depends on what names are bound. If the bound

Re: [swift-evolution] [SE-0155][Discuss] The role of labels in enum case patterns

> On Sep 4, 2017, at 11:47 AM, T.J. Usiyan wrote: > > I wasn't arguing for a strictly parallel syntax. I was arguing against being > able to omit labels. I don't view those as strictly tied together. How are > they? Like Xiaodi I don’t think it would be productive to rehash the prior discussi

Re: [swift-evolution] [SE-0155][Discuss] The role of labels in enum case patterns

> On Sep 4, 2017, at 10:52 AM, T.J. Usiyan via swift-evolution > wrote: > > While re-litigating has it's issues, I am for simplifying the rule and always > requiring the labels if they exist. This is similar to the change around > external labels. Yes, it is slightly less convenient, but it r

Re: [swift-evolution] Constrained Protocol Aliases

> On Aug 21, 2017, at 10:31 AM, Adrian Zubarev > wrote: > > > Hi Matthew thank you for remembering us about that draft. I’ll re-read it > soon. At the a quick glance I noticed the extent use of the `where` clause. > Wouldn’t make sense to simplify the main proposal and just focus on the > `

Re: [swift-evolution] Constrained Protocol Aliases

If anyone is thinking about spending time on this topic I recommend beginning by reviewing the prior work that was done by Austin Zheng. He has a proposal draft for enhanced existential that is very thorough. Even if you're not planning to propose everything that's included in his draft it wou

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

Sent from my iPad > On Aug 19, 2017, at 9:33 PM, Brent Royal-Gordon > wrote: > >> On Aug 19, 2017, at 7:41 AM, Matthew Johnson wrote: >> >> Regardless of which approach we take, it feels like something that needs to >> be implicit for structs and enums where value semantics is trivially >

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

Sent from my iPad > On Aug 19, 2017, at 3:29 PM, Michel Fortin wrote: > > >> Le 19 août 2017 à 11:38, Matthew Johnson a écrit : >> >> >> >> Sent from my iPad >> >> On Aug 19, 2017, at 8:16 AM, Michel Fortin via swift-evolution >> wrote: >> > For instance, has Array value semantics

Re: [swift-evolution] typed throws

of some kind is warranted and would have >>>> an impact on the quality of software. Maybe types aren't the right >>>> solution, but we do need one. >>>> >>>> Deciding what categories are important is obviously subjectiv

Re: [swift-evolution] typed throws

allers to discover. >>>> >>>> The output of the algorithm could use various mechanisms for >>>> categorization - an enum is one mechanism, distinct types conforming to >>>> appropriate categorization protocols is another. At

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

Sent from my iPad > On Aug 19, 2017, at 8:16 AM, Michel Fortin via swift-evolution > wrote: > >>> For instance, has Array value semantics? >> >> By the commonly accepted definition, Array does not provide value >> semantics. >> >>> You might be tempted to say that it does not because it co

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

Sent from my iPad On Aug 19, 2017, at 12:29 AM, Brent Royal-Gordon via swift-evolution wrote: >> On Aug 18, 2017, at 12:35 PM, Chris Lattner wrote: >> >>> (Also, I notice that a fire-and-forget message can be thought of as an >>> `async` method returning `Never`, even though the computatio

Re: [swift-evolution] typed throws

y (while still retaining the underlying error information for cases where the catch site requires it). Types seem like a convenient way to accomplish the goal of categorization. They are also already in use by at least some of us, but unfortunately the type information is currently discarded by t

Re: [swift-evolution] typed throws

tion I think I would be ok with that. Using wrapper types is not >> essential to solving the problem. >> >> Setting all of this aside, surely you had you had your own reasons for >> supporting typed errors in the past. What were those and why do you no >> longer consi

Re: [swift-evolution] typed throws

your own reasons for supporting typed errors in the past. What were those and why do you no longer consider them important? > > >> On Fri, Aug 18, 2017 at 6:46 PM, Matthew Johnson >> wrote: >> >>> On Aug 18, 2017, at 6:29 PM, Xiaodi Wu wrote: >>>

Re: [swift-evolution] typed throws

> On Aug 18, 2017, at 6:29 PM, Xiaodi Wu wrote: > > On Fri, Aug 18, 2017 at 6:19 PM, Matthew Johnson <mailto:matt...@anandabits.com>> wrote: > >> On Aug 18, 2017, at 6:15 PM, Xiaodi Wu > <mailto:xiaodi...@gmail.com>> wrote: >> >> On F

Re: [swift-evolution] typed throws

> On Aug 18, 2017, at 6:15 PM, Xiaodi Wu wrote: > > On Fri, Aug 18, 2017 at 09:20 Matthew Johnson via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > > > Sent from my iPad > > On Aug 18, 2017, at 1:27 AM, John McCall <mailto:rjmcc...@apple.

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

> On Aug 18, 2017, at 2:15 PM, Chris Lattner via swift-evolution > wrote: > > >> On Aug 18, 2017, at 7:19 AM, Michel Fortin > > wrote: >> >> Great writeup. Here's a few comments about the manifesto, actors and value >> semantics specifically. >> >> >> # Abo

  1   2   3   4   5   6   7   8   9   10   >