Re: [swift-evolution] String update

While we’re on the topic of regular expressions, can someone confirm if the direction that the document is taking supports naming capture groups inside repeating patterns and automatically typing them to arrays? let name = / (let firstName: String <- \w+) \s (let initials: [String] <-

Re: [swift-evolution] [pitch] adding toggle to Bool

> On 12 Jan 2018, at 07:15, Chris Eidhof via swift-evolution > wrote: > > Hey SE! > > When we have a bunch of nested structs: > > struct Sample { > var bar: Bar > } > > struct Bar { > var show: Bool > } > > var foo =

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

rties if that’s > all you’re worried about. > > Sent from my iPhone > > On Jan 8, 2018, at 15:27, David Hart via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > >> I much prefer the API from Nate Cook compared to th

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

I much prefer the API from Nate Cook compared to the previous proposal. Its simpler, while still very powerful, and closer to Swift conventions (method instead of property). > On 8 Jan 2018, at 20:02, Nate Cook via swift-evolution > wrote: > > I created a

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

> What is your evaluation of the proposal? I’m hugely in favour of the proposal but am quite worried about that fact that ValueEnumerable will not work for @objc enums and enums imported from C/Obj-C headers. It seems like a very common scenario and the lack of support for it will be both

Re: [swift-evolution] Happy new year Swift community.

Thank you very much and happy new Swift year to everybody. > On 1 Jan 2018, at 00:42, Adrian Zubarev via swift-evolution > wrote: > > Well some of you guys have to wait a little longer, but I can already wish > everyone a happy new year from Germany.  > > --

Re: [swift-evolution] Evaluating the case of an enum with associated values as a bool

> On 20 Dec 2017, at 20:24, Ethan Diamond via swift-evolution > > wrote: > > Sorry all for attaching the original post to the Non-Exhaustive enums thread. > I"m moving it down to it's own thread. > > My understanding is I'm not

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

> On 4 Dec 2017, at 10:42, Vincent Esche via swift-evolution > wrote: > > I think the argument basically is "let's not add another footgun" (because > the design of Swift , for example regarding null handling, is to have less > footguns than other languages). The

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

> On 3 Dec 2017, at 18:42, Matthew Johnson wrote: > > > > 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 >>>

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

> 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, Chris Lattner > wrote: > >> On Dec 2, 2017, at 2:13 PM, Matthew Johnson

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

The semantics of the DLR seems fairly similar to Chris’ proposal, does it not? Btw, this makes me think that I would prefer to have one proposal contain both dynamic member lookup and dynamic method calls: it would be kind of silly to have one accepted and not the other. David. > On 1 Dec

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

> On 1 Dec 2017, at 00:54, Xiaodi Wu via swift-evolution > wrote: > >> On Thu, 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 >>>

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

> On 27 Nov 2017, at 07:32, John McCall <rjmcc...@apple.com> wrote: > > >>> On Nov 22, 2017, at 2:01 AM, David Hart via swift-evolution >>> <swift-evolution@swift.org> wrote: >>> >>> >>> >>> On 22 Nov 2017, at 0

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

> On 22 Nov 2017, at 09:10, Alex Hoppen via swift-evolution > wrote: > > Would we really need the dynamicCall(method:arguments:) method and > DynamicCallableKeywordedMethod protocol for Smalltalk-like languages? > > I think in these languages, we could achieve

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

> On 22 Nov 2017, at 07:54, Douglas Gregor wrote: > > > >> On Nov 21, 2017, at 10:48 PM, David Hart > > wrote: >> >> >> >> On 22 Nov 2017, at 07:41, Douglas Gregor via swift-evolution >>

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

> On 22 Nov 2017, at 07:48, David Hart via swift-evolution > <swift-evolution@swift.org> wrote: > > > > On 22 Nov 2017, at 07:41, Douglas Gregor via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > >&

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

> On 22 Nov 2017, at 07:41, Douglas Gregor via swift-evolution > wrote: > > > >> On Nov 21, 2017, at 10:37 PM, Chris Lattner wrote: >> >> On Nov 21, 2017, at 9:25 PM, Douglas Gregor wrote: Or alternatively, one could

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

> On 21 Nov 2017, at 22:44, Douglas Gregor wrote: > > > >>> On Nov 20, 2017, at 10:31 PM, Chris Lattner wrote: >>> >>> >>> >>> On Nov 20, 2017, at 10:24 PM, David Hart wrote: >>> >>> >>> >>> On 21 Nov 2017, at 03:17, Chris

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

> On 21 Nov 2017, at 07:31, Chris Lattner wrote: > > > >> On Nov 20, 2017, at 10:24 PM, David Hart > > wrote: >> >> >> >> On 21 Nov 2017, at 03:17, Chris Lattner via swift-evolution >>

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

I have several questions/issues in this new iteration: • Why does DynamicCallableWithKeywordsToo inherit from DynamicCallable? For an interop layer for Python-style languages, we would be interested in providing conformance to DynamicCallableWithKeywordsToo (like you did in your example), but

Re: [swift-evolution] [Pitch #2] Introduce User-defined "Dynamic Member Lookup" Types

I’m very happy with this new version of the proposal. Splitting into two protocols makes a lot of sense - the JSON example alone is argument enough. To bike-shedding: while I understand the need to keep the identifier names verbose, I would prefer the subscript label to be more representative

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

> On 21 Nov 2017, at 03:17, Chris Lattner via swift-evolution > wrote: > > Yes, I agree, we need variadic generics before we can have tuples conform :-( > > At the end of the day, you want to be able to treat “(U, V, W)” as sugar for > Tuple just like we

Re: [swift-evolution] Python Interop with Swift 4+

> On 20 Nov 2017, at 21:10, Chris Lattner via swift-evolution > wrote: > > >> On Nov 20, 2017, at 10:50 AM, Slava Pestov via swift-evolution >> > wrote: >> >> >> >>> On Nov 20, 2017, at 1:39 PM, Chris

Re: [swift-evolution] Python Interop with Swift 4+

> On 20 Nov 2017, at 12:34, Brent Royal-Gordon <br...@architechies.com> wrote: > >> On Nov 20, 2017, at 12:32 AM, David Waite via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >>> On Nov 2

Re: [swift-evolution] Python Interop with Swift 4+

for approval. David. > On 20 Nov 2017, at 09:16, David Hart via swift-evolution > <swift-evolution@swift.org> wrote: > > Hi Chris, > > I’ve had a quick look into how your proposals will allow interop with other > dynamic languages. It seems that the model th

Re: [swift-evolution] Python Interop with Swift 4+

Hi Chris, I’ve had a quick look into how your proposals will allow interop with other dynamic languages. It seems that the model that you chose, where calling a function is a two-step process (getting a DynamicCallable function from a DynamicMemberLookupProtocol type) fits Python like a glove,

Re: [swift-evolution] Forums for swift.org workgroup: looking for volunteers

I’m also up for it! > On 16 Nov 2017, at 00:39, Nicole Jacque via swift-evolution > wrote: > > As Ted Kremenek has previously announced, we are in the process of moving the > Swift mailing lists to Discourse. Previously the discussion was mostly about > moving

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

I understand the sentiment, but the language has so much sugar over Optional that I wouldn’t be surprised if even seasoned developers didn't know the name of Optional’s cases. > On 15 Nov 2017, at 22:15, Ben Cohen via swift-evolution > wrote: > > I continue to

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

> On 15 Nov 2017, at 21:55, John McCall via swift-evolution > wrote: > > Hello, Swift Community! > > The initial review of "SE-0187: Introduce Sequence.filterMap(_:)" ran through > yesterday, November 14th, 2017. The proposal is available here: > >

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

> On 15 Nov 2017, at 03:56, 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

Re: [swift-evolution] [Review] SE-0189: Restrict Cross-module Struct Initializers

> What is your evaluation of the proposal? > It makes total sense. It’s a hole to plug in the resilience story. > Is the problem being addressed significant enough to warrant a change to > Swift? > Yes. > Does this proposal fit well with the feel and direction of Swift? > It feels very Swift

Re: [swift-evolution] [Review] SE-0189: Restrict Cross-module Struct Initializers

> On 14 Nov 2017, at 22:24, Jordan Rose wrote: > > Hi, David. This only affects cross-module use cases, which means that the > automatically synthesized initializer doesn’t come into play (because it’s > not public). Is the clarification you’re looking for something

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

> On 14 Nov 2017, at 20:41, Wallacy wrote: > > > > Em ter, 14 de nov de 2017 às 17:02, Mike Kluev via swift-evolution > > escreveu: > On Mon, 13 Nov 2017 22:30:25 +0100 David Hart

Re: [swift-evolution] [Review] SE-0189: Restrict Cross-module Struct Initializers

I was initially quite confused about the proposal's first sentence: "Adding a property to a public struct in Swift ought to not be a source-breaking change.” Because I nearly always rely (like many developers) on struct automatic initializers, adding a property is pretty much always a

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

> On 13 Nov 2017, at 05:52, Slava Pestov <spes...@apple.com> wrote: > > > >> On Nov 12, 2017, at 8:11 PM, Brent Royal-Gordon via swift-evolution >> <swift-evolution@swift.org> wrote: >> >>> On Nov 12, 2017, at 12:55 AM, David Hart via swi

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

Hello evolution folks, After the positive feedback on the idea of improving capturing semantics of local functions, Alex Lynch and I worked on a proposal. Please let us know if you have any feedback:

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

> On 11 Nov 2017, at 16:02, Joe Groff via swift-evolution > wrote: > > > >> On Nov 10, 2017, at 8:35 PM, Chris Lattner via swift-evolution >> wrote: >> >> >>> On Nov 10, 2017, at 6:12 PM, Slava Pestov via swift-evolution >>>

Re: [swift-evolution] JSONEncoder: Key strategies

But the transformation of the string representation of keys is a feature which other coders/decoders could use, so it might be worth pulling it out of the JSONDecoder/JSONEncoder namespace and make the implementation callable. For example, I could imagine wanting to use a similar system with

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

Yeah, I use the first form constantly. > On 6 Nov 2017, at 23:33, 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 > } > >

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

> On 26 Oct 2017, at 21:40, John McCall wrote: > >> On Oct 26, 2017, at 3:24 PM, David Hart > > wrote: >>> On 26 Oct 2017, at 21:16, John McCall via swift-evolution >>>

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

> On 26 Oct 2017, at 21:16, John McCall via swift-evolution > wrote: > >> On Oct 26, 2017, at 2:19 PM, Mike Kluev via swift-evolution >> > wrote: >> on Wed, 25 Oct 2017 13:41:40 +0200 David Hart

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

> On 25 Oct 2017, at 15:29, Matthew Johnson via swift-evolution > wrote: > > > > 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

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

> On 25 Oct 2017, at 19:01, John McCall <rjmcc...@apple.com> wrote: > >> On Oct 25, 2017, at 7:41 AM, David Hart via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> I got bit again by a sneaky memory leak con

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

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 thread (if anybody could point me to it, I’d appreciate it). Basically, here’s an example of the leak:

Re: [swift-evolution] [SPM] Roadmap?

I think what Howard Lovatt and others are hoping is for SwiftPM to add the few platform-agnostic features which are necessary for the DT team to integrate it as a first-class dependency solution for iOS projects in Xcode (build settings, bundle assets, etc…). > On 24 Oct 2017, at 13:46, Adrian

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

I also cast my vote for filterMap. It’s concise, understandable and is kind of a term of art also. > On 24 Oct 2017, at 02:56, BJ Homer via swift-evolution > wrote: > > I agree with Xiaodi; I like ‘filterMap’ more than ‘filteredMap’. But both are > superior to

Re: [swift-evolution] [Draft] Rename Sequence.elementsEqual

+1 Agree with the reasoning and that this is the best solution. It reduces the risk of confusing the function for what it’s not. > On 13 Oct 2017, at 01:37, Kelvin Ma via swift-evolution > wrote: > > I’ve always hated the use of the word “lexicographically” in that

Re: [swift-evolution] Property Getter Return Statement

> On 7 Oct 2017, at 19:22, Tony Allevato via swift-evolution > wrote: > > I think the important thing to consider is, what advantage would such a > feature provide *other* than to reduce keystrokes? (I don't personally think > that optimizing for keys pressed by

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

One argument: without this fix, private is the only access level for which we have no means to easily and implicitly apply an access level to a group of members. And it bums me to have to explicitly type private on ever single member to achieve the same result as I can with any other access

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

> On 6 Oct 2017, at 06:25, David Hart via swift-evolution > <swift-evolution@swift.org> wrote: > > > >> On 5 Oct 2017, at 20:23, Ben Cohen via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> >>> On Oct 5, 2017, a

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

> On 5 Oct 2017, at 20:23, Ben Cohen via swift-evolution > wrote: > > >> On Oct 5, 2017, at 10:58, Nate Cook via swift-evolution >> wrote: >> >> The edge case is really the same (empty ranges), it’s about what we do with >> the edge

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

at says ‘private extension’ was written in a Swift 3 or >>> 4 era when ‘fileprivate’ was an option. If the goal was specifically to >>> share it with the whole file, it seems likely that most authors would have >>> used ‘fileprivate extension’ instead of ‘private extension’, as that bette

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

> On 4 Oct 2017, at 07:16, Chris Lattner via swift-evolution > wrote: > > >> On Oct 3, 2017, at 10:11 PM, Slava Pestov > > wrote: >> However I’m still waiting for Dave or Jordan to chime in with the original

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

> On 4 Oct 2017, at 07:11, Slava Pestov via swift-evolution > wrote: > > > >> On Oct 3, 2017, at 10:09 PM, Chris Lattner > > wrote: >> >> On Oct 3, 2017, at 9:59 PM, Slava Pestov >

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

> On 3 Oct 2017, at 05:12, Xiaodi Wu via swift-evolution > wrote: > >> On Mon, Oct 2, 2017 at 9:16 PM, Matthew Johnson via swift-evolution >> wrote: >> >> >> Sent from my iPad >> >>> On Oct 2, 2017, at 7:33 PM, Jordan Rose via

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

> On 2 Oct 2017, at 06:39, Ted Kremenek via swift-evolution > wrote: > > >> On Oct 1, 2017, at 4:00 AM, Haravikk via swift-evolution >> > wrote: >> >>> >>> On 14 Sep 2017, at 20:10, Ben Rimmington

Re: [swift-evolution] Re-pitch: remove(where:)

> On 27 Sep 2017, at 01:14, Ben Cohen via swift-evolution > wrote: > > And here are my answers, in a separate email to maintain a shred of > separation between objectivity and subjectivity :) > >> On Sep 26, 2017, at 4:12 PM, Ben Cohen via swift-evolution >>

Re: [swift-evolution] Enums and Source Compatibility

> On 18 Sep 2017, at 19:20, Jordan Rose wrote: > > That's pretty much the same as this proposal except you don't have the new > keyword. I'm not sure why that really makes a difference, since they're > obviously paired, and it would limit existing libraries from

Re: [swift-evolution] Enums and Source Compatibility

I’m still very much bothered by having 2 new keywords. I would really prefer the following plan: Exhaustive by default in Swift 4 No new keyword in Swift 4 to change that behaviour Non-exhaustive by default outside the module in Swift 5 exhaustive keyword to change the default behaviour Like

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

> On 12 Sep 2017, at 06:45, Brent Royal-Gordon via swift-evolution > wrote: > >> On Sep 9, 2017, at 10:31 PM, Chris Lattner via swift-evolution >> wrote: >> >> - I’d love to see several of the most common random kinds supported, and I

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

> On 10 Sep 2017, at 00:40, Kenny Leung via swift-evolution > wrote: > > Then isn’t the example functionally equivalent to: > > func doit() { > DispatchQueue.global().async { > let dataResource = loadWebResource("dataprofile.txt") >

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

> On 8 Sep 2017, at 23:01, Matthew Johnson via swift-evolution > wrote: > > >> On Sep 8, 2017, at 2:30 PM, Ben Cohen via swift-evolution >> > wrote: >> >> Hi Alejandro, >> >> I’m really happy to see

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

> On 8 Sep 2017, at 20:34, Kenny Leung via swift-evolution > wrote: > > Hi All. > > A point of clarification in this example: > > func loadWebResource(_ path: String) async -> Resource > func decodeImage(_ r1: Resource, _ r2: Resource) async -> Image > func

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

> On 7 Sep 2017, at 07:05, Chris Lattner via swift-evolution > wrote: > > >> On Sep 5, 2017, at 7:31 PM, Eagle Offshore via swift-evolution >> wrote: >> >> OK, I've been watching this thing for a couple weeks. >> >> I've done a lot of

Re: [swift-evolution] Enums and Source Compatibility

Hi Jordan, I like this new direction. But I have Rod’s inverse question: have you considered only having the nonexhaustive keyword? Similar to how non-final doesn't exist because its opposite is the default behaviour. That would also free us from searching for a good pair of keywords and only

Re: [swift-evolution] [Concurrency] A slightly different perspective

> On 3 Sep 2017, at 18:03, Chris Lattner wrote: > > >>> On Sep 3, 2017, at 4:00 AM, David Hart wrote: >>> >>> Please don’t read too much into the beginAsync API. It is merely a >>> strawman, and intended to be a low-level API that higher level

Re: [swift-evolution] [Concurrency] A slightly different perspective

> On 2 Sep 2017, at 20:24, Chris Lattner via swift-evolution > wrote: > > On Aug 31, 2017, at 3:04 PM, Nathan Gray via swift-evolution > wrote: >> I've been following the conversations around Chris Lattner's intriguing >> async/await

Re: [swift-evolution] [Concurrency] Fixing race conditions in async/await example

>> The main difference, and I would argue an improvement, is that the `Future` >>> version handles errors. >>> >>> So what advantage does async/await have over a `Future` library we can >>> write today? >>> >>> >>> -- Howard. >>

Re: [swift-evolution] [Concurrency] Fixing race conditions in async/await example

improvement, is that the `Future` > version handles errors. > > So what advantage does async/await have over a `Future` library we can write > today? > > > -- Howard. > > On 29 August 2017 at 15:28, David Hart via swift-evolution > <swift-evolution@swift.org <

Re: [swift-evolution] [Concurrency] Fixing race conditions in async/await example

> On 29 Aug 2017, at 02:22, Xiaodi Wu via swift-evolution > wrote: > > On Mon, Aug 28, 2017 at 16:10 Adam Kemp via swift-evolution > > wrote: > I know what the proposal said. I’m making a case that there

Re: [swift-evolution] [Concurrency] Fixing race conditions in async/await example

> On 28 Aug 2017, at 23:14, Jean-Daniel via swift-evolution > wrote: > > >> Le 28 août 2017 à 06:14, Howard Lovatt via swift-evolution >> a écrit : >> >> One of the biggest incumbents in this space on the server side is Java and >>

Re: [swift-evolution] await keyword "scope"

> On 28 Aug 2017, at 22:37, Adam Kemp via swift-evolution > wrote: > > I explained what the value is already. It identifies clearly in your code > where the suspension points are. Each place you see “await” would mark a > location where your code may yield and

Re: [swift-evolution] New async keyword usage

> On 27 Aug 2017, at 06:09, Wallacy via swift-evolution > wrote: > > Chris's proposal is very explicit about the advantages of the async/await > over the Future/Task, we don't need to rephrase here. The most obvious > advantage of course is because "await" does not

Re: [swift-evolution] [Concurrency] Async/Await

Sorry for the shameless bump :-/ but I’d love to get some answers so I can better understand the proposal and participate in the discussions. > On 21 Aug 2017, at 07:58, David Hart via swift-evolution > <swift-evolution@swift.org> wrote: > > Hello, > > Thanks for the

Re: [swift-evolution] Constrained Protocol Aliases

> On 21 Aug 2017, at 13:36, Adrian Zubarev > wrote: > > It’s part of Generalized Existentials, but does not make it complete. I think > it would be worth adding more and more functionality to existentials every > year. We started first with reshaping the

Re: [swift-evolution] Constrained Protocol Aliases

> On 21 Aug 2017, at 11:41, Adrian Zubarev > wrote: > > Yes, `where` clause is welcome to typealises (including generic ones) and > existentials in general. I would love to help on such proposal. I think David > Hart is also interested in this one. (cc) Yes,

[swift-evolution] [Concurrency] Async/Await

Hello, Thanks for the great work on the async/await proposal! After reading it, I have a few questions and comments about it, so I’m creating this thread to concentrate on that topic (instead of Actors). Generators The proposal mentions in Problem 6 of the Motivation how generators can help

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

> On 20 Aug 2017, at 01:17, 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 async/await to land, and the >>

Re: [swift-evolution] Enums and Source Compatibility - defaults

> On 10 Aug 2017, at 19:19, Jordan Rose wrote: > > > >>> On Aug 9, 2017, at 22:46, David Hart wrote: >>> >>> >>> On 10 Aug 2017, at 02:42, Jordan Rose wrote: >>> >>> :-) As you've all noted, there are some conflicting

Re: [swift-evolution] Enums and Source Compatibility - defaults

ed >> differently in Swift; closed is a sensible default. We shouldn’t need to >> define new keywords and increase the surface area of the language for >> something that has verisimilitude with the existing open syntax. >> >> Sincerely, >> Zachary Waldowski >&

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

> On 10 Aug 2017, at 07:20, Adrian Zubarev via swift-evolution > wrote: > > Hi there, I don’t mean to be rude or something, nor do I want to hold the > review process up from succeeding, but where is the branch with the > implementation? > > Quote: > > The

Re: [swift-evolution] private extension

47, Xiaodi Wu <xiaodi...@gmail.com> wrote: >>> >>> I brought this up after SE-0169, but it was deemed to be a separate issue >>> and any further consideration was declined. Let’s not initiate another >>> round of access control discussions. >>>>

Re: [swift-evolution] private extension

t it was deemed to be a separate issue and > any further consideration was declined. Let’s not initiate another round of > access control discussions. >> On Wed, Aug 9, 2017 at 16:31 David Hart via swift-evolution >> <swift-evolution@swift.org> wrote: >> Actually,

Re: [swift-evolution] private extension

, I think we should fix this. > On 9 Aug 2017, at 23:22, David Hart via swift-evolution > <swift-evolution@swift.org> wrote: > > That behaviour was never explicitly mentioned in SE-0169 but I agree its > confusing. But I’m also fairly sure the only window to do anything a

Re: [swift-evolution] private extension

That behaviour was never explicitly mentioned in SE-0169 but I agree its confusing. But I’m also fairly sure the only window to do anything about it is Swift 4. Everybody is really worn down by those access level discussions. For illustration, Vladimir is confused that: private extension Foo {

Re: [swift-evolution] Enums and Source Compatibility

> On 9 Aug 2017, at 09:21, Adrian Zubarev via swift-evolution > wrote: > > Hi Jordan, is that only me or haven't you metioned the default should be > applied to all new enums? Personally I'd say that 'closed' should be the > default and the 'open' enum would

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

Don’t small arrays live on the stack? > On 4 Aug 2017, at 06:35, Félix Cloutier via swift-evolution > wrote: > > As far as I can tell, currently, all arrays live on the heap. > >> Le 3 août 2017 à 19:03, Robert Bennett via swift-evolution >>

Re: [swift-evolution] Why you can't make someone else's class Decodable: a long-winded explanation of 'required' initializers

> On 3 Aug 2017, at 08:00, Slava Pestov wrote: > > >> On Aug 2, 2017, at 10:48 PM, David Hart > > wrote: >> >> Somewhat related: I have a similar problem in a project where I need two >> different Codable conformances for a

Re: [swift-evolution] Why you can't make someone else's class Decodable: a long-winded explanation of 'required' initializers

Thanks for the detailed explanation Jordan! Comment inline: > On 3 Aug 2017, at 02:08, Jordan Rose wrote: > > David Hart recently asked on Twitter > if there was a good > way to add Decodable support to somebody

Re: [swift-evolution] RFC: structuring forums for best use for swift-evolution

> On 2 Aug 2017, at 09:44, Tino Heth via swift-evolution > wrote: > > Thanks for the update! > >> - We currently have swift-evolution and swift-evolution-announce. Should >> we use a specific “category” in the forum for "proposals that are in active >> review" —

Re: [swift-evolution] Moving from Swift 2 to 4

> On 26 Jul 2017, at 14:37, Jonathan Hull via swift-evolution > wrote: > > Is there a reason why the migration only applies to Swift 3? I have some > older files which I haven’t gotten around to upgrading until now, and Xcode > Beta says I need to migrate them

Re: [swift-evolution] Idea: Exposing _JSONEncoder and _JSONDecoder functionality

> On 25 Jul 2017, at 18:45, Itai Ferber via swift-evolution > wrote: > > Hi Morten, > > This is something we’ve considered adding and may do so in the future — > however, this will require additional API review and will not make it in time > for the Swift 4.0

Re: [swift-evolution] [Review] SE-0182 - String Newline Escaping

I can, but it felt more odd to me than a blank line. But that's debatable. > On 20 Jul 2017, at 01:40, Chris Lattner <clatt...@nondot.org> wrote: > > >> On Jul 17, 2017, at 4:43 AM, David Hart via swift-evolution >> <swift-evolution@swift.org> wrote: >&

Re: [swift-evolution] [Review] SE-0182 - String Newline Escaping

ions though and could live with either. > > -John > >> On 14 Jul 2017, at 18:17, Jordan Rose via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> >> >>> On Jul 14, 2017, at 10:00

Re: [swift-evolution] [Review] SE-0182 - String Newline Escaping

> On 14 Jul 2017, at 00:21, Jordan Rose wrote: > > [Proposal: > https://github.com/apple/swift-evolution/blob/master/proposals/0182-newline-escape-in-strings.md > > ] > >

Re: [swift-evolution] [Pitch] Guard/Catch

> On 10 Jul 2017, at 09:45, Elviro Rocca via swift-evolution > wrote: > > This is not a sugar proposal, in the same way as "guard" is not syntactic > sugar, because it requires exiting the scope on the else branch, adding > expressive power and safety to the call:

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

> On 30 Jun 2017, at 07:23, Brent Royal-Gordon via swift-evolution > wrote: > >> On Jun 27, 2017, at 10:16 AM, Erica Sadun via swift-evolution >> wrote: >> >> Using an operator to provide feedback on the context of a failed unwrap has

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

> On 29 Jun 2017, at 12:37, Elviro Rocca wrote: > > From the user's standpoint, a crash is the worst thing possible, and should > always be avoided. A failure doesn't need to be silent for user, the app can > still communicate that there was an error with some

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

> On 29 Jun 2017, at 09:19, Elviro Rocca via swift-evolution > wrote: > > >> Il giorno 29 giu 2017, alle ore 03:18, Ben Cohen via swift-evolution >> ha scritto: >> >> Finally, there’s a woolier justification: there’s an often-touted

Re: [swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

a swift-evolution >>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>>> I feel that the !! operator would be necessary for indicating that if this >>>> fails then something went horribly wrong somewhere and we should throw the >

  1   2   3   4   5   6   >