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

> Another option that reads nicely IMHO is > > func fn(param: T) throws -> T where T : Equatable [foo, bar] { … } > I changed my mind. Putting the capture list just before { } is where I'd rather see it. > I think #4 is ambiguous with array literals unfortunately. > > Perhaps this proposal

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

> On Nov 12, 2017, at 8: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] [Pitch] Improving capturing semantics of local functions

I'd vote for # 1 Starting with "func" helps signal that the context is a function. (Though I know some things can precede "func".) Having the function name second is important to me: you don't have to scan further for its name. Template arguments seem more important than capture lists, so

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

If a generator should return an associated type, what if the associated type for Random? I assume people will want this to be UInt32. Yea I think I’m going to keep returning an optional on all collections/ranges and getting rid of Int.random(in:). I still agree it’s less discoverable, but I

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

> 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 improving capturing semantics of > local functions, Alex Lynch and I worked on a proposal. Please let us know if > you

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

On Sun, Nov 12, 2017 at 19:47 Alejandro Alonso wrote: > Sorry I’ve been gone for a while, I had to do a lot of traveling. > > 1. Initially I made this thinking that developers had the power to > determine their own lower bound. The current implementation uses the >

Re: [swift-evolution] When exactly 1 function matches a call site, should it be called or cause a compiler error?

> On Nov 12, 2017, at 7:27 PM, Nevin Brackett-Rozinsky > wrote: > > On Sun, Nov 12, 2017 at 10:16 PM, Slava Pestov > wrote: >> Pardon my lack of imagination, but could you provide an example of a call >> site

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

> On Nov 8, 2017, at 9:29 PM, Paul Cantrell via swift-evolution > wrote: > > The problem in the Doodads example is that the name flatMap is used to > identify two distinct intents: concatenating arrays and filtering nils. One > can argue that those two operations

Re: [swift-evolution] When exactly 1 function matches a call site, should it be called or cause a compiler error?

On Sun, Nov 12, 2017 at 10:16 PM, Slava Pestov wrote: > > Pardon my lack of imagination, but could you provide an example of a call > site that would become ambiguous? > > > protocol P {} > protocol Q {} > struct S : P, Q {} > > struct Outer { > static func foo(_: P) {} > >

Re: [swift-evolution] When exactly 1 function matches a call site, should it be called or cause a compiler error?

> On Nov 12, 2017, at 7:14 PM, Nevin Brackett-Rozinsky > wrote: > > On Sun, Nov 12, 2017 at 8:44 PM, Slava Pestov > wrote: > Yeah, this is an unfortunate wart. Right now unqualified lookup starts at the >

Re: [swift-evolution] When exactly 1 function matches a call site, should it be called or cause a compiler error?

On Sun, Nov 12, 2017 at 8:44 PM, Slava Pestov wrote: > Yeah, this is an unfortunate wart. Right now unqualified lookup starts at > the innermost scope and stops when it finds a candidate which matches the > name being looked up. Overload sets are only formed if there are

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

Sorry I’ve been gone for a while, I had to do a lot of traveling. 1. Initially I made this thinking that developers had the power to determine their own lower bound. The current implementation uses the integer’s min value as a lower bound. If it makes sense to only allow unsigned integers from

Re: [swift-evolution] When exactly 1 function matches a call site, should it be called or cause a compiler error?

Yeah, this is an unfortunate wart. Right now unqualified lookup starts at the innermost scope and stops when it finds a candidate which matches the name being looked up. Overload sets are only formed if there are multiple candidates inside the same scope, not in different scopes. It would be

[swift-evolution] When exactly 1 function matches a call site, should it be called or cause a compiler error?

I brought this up on Swift Dev and was told to check on Swift Evolution to see if a proposal is needed. Currently, the following code produces a compiler error: func foo(_ x: Int, _ y: Int) -> Int { return x + y } extension Int { func foo() -> Int { return foo(self, self)// Error

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

> On Nov 12, 2017, at 3:33 AM, Tino Heth via swift-evolution > wrote: > > > >> Am 11.11.2017 um 19:03 schrieb Chris Lattner > >: >> >>> Swift is quite flexible on what can act as a closure — would it be allowed >>> to

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

One last try at promoting code generators as an alternative means of importing…. It keeps the complexity out of the compiler and you are able to write the “importer” in the language being imported allowing it to leverage it’s meta data introspection directly. I’ve prepared a playground which

Re: [swift-evolution] async void

>From what I understand, the C# and Swift designs are different: - C# async functions immediately return a task which can be enqueued to complete the work (including selecting which queue for UI cases, etc). Tasks have callback behavior attached to them. - Swift async functions immediately

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

On Sun, Nov 12, 2017 at 1:37 PM, Tony Allevato wrote: > > > On Sat, Nov 11, 2017 at 1:53 PM Xiaodi Wu wrote: > >> On Sat, Nov 11, 2017 at 3:15 PM, Tony Allevato >> wrote: >> >>> >>> >>> On Sat, Nov 11, 2017 at 10:28 AM

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

On Sat, Nov 11, 2017 at 1:53 PM Xiaodi Wu wrote: > On Sat, Nov 11, 2017 at 3:15 PM, Tony Allevato > wrote: > >> >> >> On Sat, Nov 11, 2017 at 10:28 AM Xiaodi Wu wrote: >> >>> On Sat, Nov 11, 2017 at 11:23 AM, Tony Allevato

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

> On Nov 11, 2017, at 8:35 AM, Gwendal Roué via swift-evolution > wrote: > > I'd suggest `compactMap` as an alternative name, should `filterMap` find too > much resistance: I like that name too, though it’s probably my Ruby experience showing. I like the clarity

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

On Sun, Nov 12, 2017 at 4:54 AM, Brent Royal-Gordon wrote: > On Nov 10, 2017, at 11:01 PM, Xiaodi Wu wrote: > > Nit: if you want to call it `ValueEnumerable`, then this should be > `DefaultValueCollection`. > > > I used `DefaultCaseCollection`

Re: [swift-evolution] Abstract methods

I think there is a legitimate hole around abstract methods. I don’t think it really matters whether you’re talking about a class hierarchy or a protocol hierarchy. They’re both providing partial implementations of behaviour, predicated on some other method being implemented. The practical

Re: [swift-evolution] async void

Sorry, I'm just getting into this conversation late and am by no means experienced in the area, but why can't the one where you *don't* want the caller to wait for the result be spelled `async -> Never`? Theoretically, `async -> Void` means you're awaiting a result with only one possible value,

Re: [swift-evolution] async void

Sorry, I had got some confusion. Please let me retry to explain. As you said, C# provides three kinds of async functions: `async Void`, `async Task` and `async Task`. All of them are necessary and Swift should provide same functionalities. When we think about `async/await` in Swift, because we

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

> On Nov 11, 2017, at 7:02 AM, Joe Groff via swift-evolution > wrote: > > Opening up the compiler architecture to make custom importers easier to write > is a great solution to a ton of problems, including yours I think, without > adding complexity to the core

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

> Am 11.11.2017 um 19:03 schrieb Chris Lattner : > >> Swift is quite flexible on what can act as a closure — would it be allowed >> to use a dynamic callable in that context? >> I guess forwarding of >> >> let closure: ([(String, Int)]) -> Int = DynamicCallableType() >> >>

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

Imho it’s good to copy the concept of capture lists — but it could be done differently, without polluting the body: func foo[capture list](parameters) {} I’m not sure if there are corner cases with subscript-syntax, but in general, I think this approach is nicer. - Tino

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

> On Nov 10, 2017, at 11:01 PM, Xiaodi Wu wrote: > > Nit: if you want to call it `ValueEnumerable`, then this should be > `DefaultValueCollection`. I used `DefaultCaseCollection` because, although the protocol can work with any type to return its values, this type can

[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: