> On Oct 27, 2017, at 9:42 PM, Howard Lovatt via swift-evolution
> <[email protected]> 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 because now named local functions will look quite different from local
functions today:
let myLocalFn = { (x: Int, y: Int) in x + y }
vs
func myLocalFn(x: Int, y: Int) { return x + y }
Is that really an improvement? It looks different from non-local functions.
> 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
Ok, but again, how is this better than local functions?
>
> 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
Local types cannot capture values from outer scopes right now, so this does not
give you the full power of a closure.
The trouble with closures having their own generic parameter lists is that
closures are values. So imagine you could write:
let fn = { <T> (x: T) -> T in x }
What is the type of ‘fn’?
You should be able to do,
fn(3)
fn(“hello”)
So fn has a polymorphic type. Now when a polymorphic closure is appears
immediately on the right hand side of a ‘let’ binding, it is equivalent to a
local function today. But you can also do stuff like
let fn1 = { <T> (x: T, y: T) -> T in x }
let fn2 = { <T> (x: T, y: T) -> T in y }
let myFn = foo ? fn1 : fn2
Now ‘myFn’ is a value with a polymorphic type that is not immediately known to
be a closure literal. Actually implementing this properly would require a
substantial rework of all layers of the compiler and runtime.
I’m not saying any of this is impossible. It could certainly all be implemented
with enough effort. However, there are two general concerns I have with all of
this:
1) Does implementing this functionality justify the cost, both in terms of
potential regressions, or just the opportunity cost in the team not spending
the time working on something else?
2) How is it actually an improvement over local functions? If we make local
functions look like closures, what have we actually gained? Local functions
have the advantage that they look like functions — so a generic local function
reads naturally to someone who’s used Swift before but has never seen a local
function. On the other hand, a generic closure expression, were such a thing to
exist, would be a new syntax that presumably would only appear in source
rarely, confusing someone when they first encounter it.
Perhaps what we really need is better control over captures from local
functions. Adding capture lists to local functions is something I would not be
opposed to for instance, and should be possible to implement without much pain.
Slava
>
> 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
> <[email protected] <mailto:[email protected]>> 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 <[email protected]
> > <mailto:[email protected]>> 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
> >> <[email protected] <mailto:[email protected]>> 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
> [email protected] <mailto:[email protected]>
> https://lists.swift.org/mailman/listinfo/swift-evolution
> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>
> _______________________________________________
> swift-evolution mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
