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

> On Oct 26, 2017, at 10:27 PM, Howard Lovatt wrote: > > > Closures cannot replace all uses of local functions. Local functions can be > > recursive, and have a generic parameter list. > > My response would be add these featurtes to closures, it will make closures > better. Since closures a

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

> Closures cannot replace all uses of local functions. Local functions can be recursive, and have a generic parameter list. My response would be add these featurtes to closures, it will make closures better. In terms of recursion you can fiddle it: struct RecursiveClosure { var c: C! = nil }

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

> On Oct 26, 2017, at 9:53 PM, Howard Lovatt via swift-evolution > wrote: > > It would be easy to provide a fixit. That is still a source breaking change that requires migration, though. > How often are they actually used? I rarely use them and all my use cases > could be a closure instead.

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

It would be easy to provide a fixit. How often are they actually used? I rarely use them and all my use cases could be a closure instead. Also see Mike Kluev example; local functions are arguably worse than closures in all cases (provided that you can appropriately annotate the function type).

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

Allow function types that are both let and initialized to be annotated with @inline. If closures get more features then we fix the bug pointed out with local functions and we get better closures. Good bang for the buck. -- Howard. On 27 October 2017 at 12:22, Taylor Swift wrote: > i use a lot

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

On 27 October 2017 at 00:45, Howard Lovatt wrote: > Rather than expand local function syntax why not deprecate local functions > completely > a cautious +0.5. local functions do not add that much value as one would hope and beyond what's already discussed above, unfortunately break one major pr

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

> On Oct 26, 2017, at 4:45 PM, Howard Lovatt via swift-evolution > wrote: > > Rather than expand local function syntax why not deprecate local functions > completely I don’t think at this point such a drastic change to the language is likely to happen. Slava

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

i use a lot of local @inline(__always) functions as a sort of weird macro so this change would be hugely source breaking. Also can you even annotate a function object as force-inlineable? > On Oct 26, 2017, at 6:45 PM, Howard Lovatt via swift-evolution > wrote: > > The issues raised about loc

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

The issues raised about local capture by local (inner) functions are valid, likewise the discussion about the @nonescaping annotation are also valid. Rather than expand local function syntax why not deprecate local functions completely and add the @nonescaping annotation to local closures followin

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

On 26 October 2017 at 20:24, David Hart wrote: > I don’t see how this makes any sense or be possible: > > * It doesn’t make sense for me because local is not a member function of A. > * It would cause ambiguity when trying to call another member function > with the same name as the local function

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

I wrote about this in 2015 http://alejandromp.com/blog/2015/6/24/swift-flatmap/ and forgot about it. I just get used to it now but it's still hard to explain to newcomers why flatMap has this "special" behaviour on Swift. I'm not an expert on functional programming but if this doesn't make sense in

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

> On Oct 26, 2017, at 3:24 PM, David Hart wrote: >> On 26 Oct 2017, at 21:16, John McCall via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >>> On Oct 26, 2017, at 2:19 PM, Mike Kluev via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> on Wed, 25 Oct 2017 13:

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 >> mailto:swift-evolution@swift.org>> wrote: >> on Wed, 25 Oct 2017 13:41:40 +0200 David Hart > > wrote: >> >> class A { >> func

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

> 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 > wrote: > > class A { > func foo() { > func local() { > bar() // error: Call to method ‘bar' in function ‘local' requires >

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

On 26 October 2017 at 19:19, Mike Kluev wrote: > on Wed, 25 Oct 2017 13:41:40 +0200 David Hart wrote: > > class A { >> func foo() { >> func local() { >> bar() // error: Call to method ‘bar' in function ‘local' >> requires explicit 'self.' to make capture semantics explici

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

on Wed, 25 Oct 2017 13:41:40 +0200 David Hart wrote: class A { > func foo() { > func local() { > bar() // error: Call to method ‘bar' in function ‘local' > requires explicit 'self.' to make capture semantics explicit > } > > // ... > } > } > it's not o

Re: [swift-evolution] [draft] Target environment platform condition

> On Oct 26, 2017, at 8:43 AM, Karl Wagner via swift-evolution > wrote: > > it’s not like I don’t understand when you’d want some different behaviour in > a program to account for the simulator’s environment. I just wonder if it’s > worth being a built-in part of the language. To me, it feel

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

+1 -Thorsten > Am 25.10.2017 um 21:47 schrieb Howard Lovatt via swift-evolution > : > > To clarify. I meant the infrastructure for IDE integration with Xcode as one > of the IDEs that used that infrastructure. > > -- Howard. > >> On 24 Oct 2017, at 11:26 pm, David James via swift-evolutio

Re: [swift-evolution] [draft] Target environment platform condition

it’s not like I don’t understand when you’d want some different behaviour in a program to account for the simulator’s environment. I just wonder if it’s worth being a built-in part of the language. To me, it feels like something better suited to an ad-hoc build option or global constant. OS, CP

Re: [swift-evolution] [draft] Target environment platform condition

Example: the iOS Keychain APIs do not support access groups on the simulator, so if you try to make a keychain query that targets an access group, you get no results. This means that in order for my app to operate correctly on simulator, I need to pass different parameters on simulator and devic

Re: [swift-evolution] [draft] Target environment platform condition

I’m currently -1 on this, because I don’t think simulator/device is a worthwhile-enough distinction for a built-in condition. - Are you maybe looking for a Debug/Release condition? Because we already have that, through compile-time variables (the “-D” option). - Does your platform’s simulator/em

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

> On 25. Oct 2017, at 13:41, 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 thread (if anybody could

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

Hi, > On 25 Oct 2017, at 6:01 pm, John McCall via swift-evolution > wrote: > >> 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