[swift-evolution] Making capturing semantics of local

[Howard Lovatt]

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
much difference between a function and a closure and because the function
behaviour is easy to fake and therefore something the compiler could do (in
fact do better than you can fake). Two of the example presented of things
closures can't do are mutual recursion and generics, both are fakable:

var isEven: ((UInt) -> Bool)! = nil // Forward declaration!
var isOdd: ((UInt) -> Bool)! = nil
isEven = { n in
    if n == 0 {
        return true
    } else {
        return isOdd(n - 1)
    }
}
isOdd = { n in
    if n == 0 {
        return false;
    } else {
        return isEven(n - 1)
    }
}
isEven(4) // True
isOdd(4) // False

struct GenericIncrement<T: Numeric> {
    let increment = { (n: T) -> T in
        n + 1
    }
}
let int = GenericIncrement<Int>() // Reify increment and name mangle!
int.increment(1) // 2
let double = GenericIncrement<Double>()
double.increment(1.1) // 2.1


The reason for showing code above is to demonstrate that the compiler could
do this (in fact it could do better) - I am not suggesting anyone uses the
above!

  -- Howard.

On 28 October 2017 at 10:01, Slava Pestov via swift-evolution <
swift-evolution at swift.org> wrote:

> 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 <swiftevolution at jongilbert.com>
> wrote:
> >
> > 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
> variables themselves are function types that do the wrapping, and therefore
> take closures as arguments. (Of course, all of these closures taking
> generic arguments conforming to protocols with associated types made things
> extra interesting.)
> >
> > I don’t know if this makes local functions actively harmful, or if it
> means function types in capture lists need to support @escaping, but it
> does remind me to go back and try to reproduce those weird issues in a
> sample project or playground page so I can make a bug report to Apple.
> >
> > Jonathan
> >
> >> On Oct 27, 2017, at 12:29, Slava Pestov via swift-evolution <
> swift-evolution at swift.org> wrote:
> >>
> >> I mean, we could remove a lot of language features without giving up
> turing completeness. But I’ve personally used local functions in multiple
> languages and found them useful. I certainly don’t see why the feature is
> actively harmful, which is the criteria for introducing a source breaking
> change in Swift 5.
> >
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171028/2f0f5f52/attachment.html>