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

> On Oct 27, 2017, at 9:42 PM, Howard Lovatt via swift-evolution > wrote: > > I should qualify that I am not proposing removing local functions without > replacing them with closures that have the same power. If we can unify the two syntaxes, maybe. But even if that was possible, I’m leery

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

I should qualify that I am not proposing removing local functions without replacing them with closures that have the same power. I don't believe powerful closures are something the compiler couldn't do, in fact I believe it is something that is relatively easy. I believe this because there isn't mu

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

That sounds like a bug, and it could occur with closure expressions also, since at the SILGen level and below they’re basically the same thing. Please file a bug if you come up with a reduced test case. Slava > On Oct 27, 2017, at 4:00 PM, Jon Gilbert > wrote: > > I have run into nondescript

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

I have run into nondescript compiler crashes (like segmentation faults, etc.) when using local functions to do certain things, like wrapping the parent function’s escaping closure arguments in other closures that capture variables from the parent function’s local scope, especially when those var

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

> On Oct 27, 2017, at 10:51 AM, Mike Kluev wrote: > > On Thu, 26 Oct 2017 21:54:37 -0700 Slava Pestov > wrote: > > Closures cannot replace all uses of local functions. Local functions can be > recursive, and have a generic parameter list. > > > FTM, local function

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

I use local functions heavily in my day-to-day workflow and an very interested in them supporting capture lists. Here is a draft feature specification: https://bitbucket.org/snippets/lynchrb/r487zn Anyone see any weak spots? Alex On Fri, Oct 27, 2017 at 12:54 AM, Slava Pestov via swift-evolution

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. > > stack class StackObjec

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

on Date: Fri, 27 Oct 2017 17:52:54 +0100 Johannes Weiß < johanneswe...@apple.com> wrote: > On 27 Oct 2017, at 6:27 am, Howard Lovatt via swift-evolution < > swift-evolution@swift.org> wrote: > > > > In terms of recursion you can fiddle it: > > > > struct RecursiveClosure { > > var c: C! = nil

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

On Thu, 26 Oct 2017 21:54:37 -0700 Slava Pestov wrote: > > Closures cannot replace all uses of local functions. Local functions can > be recursive, and have a generic parameter list. > > FTM, local functions do not help with "keep functions short" and "keep indentation level small" rules of thumb

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

> On 27 Oct 2017, at 6:27 am, Howard Lovatt via swift-evolution > 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 > bett

Re: [swift-evolution] stack classes

I’m highly supportive of this, but this pitch is incomplete. Unless we restrict stack-classes to be non-escaping, and non copyable, at the minimum we need to force the user to implement a copy initializer as well as deinit. If we also want to support moves, this could make the compiler diagnostics

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. That text has a line which illustrates the source of dissent: > It’s kind of combining map (to apply the function), flatten (to unwr

Re: [swift-evolution] stack classes

Hello, It looks like you want compiler guarantees that an object will be "deinited" at the end of a syntactic block: func f() { let a = Object() ... // <- guarantee that a.deinit is called here } Currently, Swift does not grant suc

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. That text has a line which illustrates the source of dissent: > It’s kind of combining map (to apply the function), flatten (to unwr

Re: [swift-evolution] stack classes

Could you explain more about your use case? I am not sure I understand the motivation… Also, what are you hoping to dealloc in structs? Thanks, Jon > On Oct 27, 2017, at 6:27 AM, Mike Kluev via swift-evolution > wrote: > > if it wasn't already discussed here is the preliminary proposal, if

[swift-evolution] stack classes

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. stack class StackObject { // guaranteed to be on stack } class NonStackObject { // is not guaranteed to be on stac

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

> On 26. Oct 2017, at 17:13, Dave DeLong via swift-evolution > wrote: > > >> On Oct 26, 2017, at 8:43 AM, Karl Wagner via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> it’s not like I don’t understand when you’d want some different behaviour in >> a program to account

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 >>> mailto:swift-evolution@swift.org>> wrote: >>> On Oct 26, 2017, at 2:19 PM, Mike Kluev via swif

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

I'm not attached to the name filteredMap, but having a specific signature for the optional version makes sense. I think the problem is that while Optional can be contemplated as a sequence of zero or one items, implicit conversion to Optional means anything can then be interpreted as a collect