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

[Howard Lovatt]

I think you have changed my mind. Virtually everything I want to do can be
achieved by having a closure as an alternative syntax for a function.
Particularly if you could assign to a `var`. You still need extra syntax
for generics and escaping closures.

On Fri, 17 Nov 2017 at 1:45 pm, Slava Pestov <spestov at apple.com> wrote:

>
> On Nov 16, 2017, at 4:38 PM, Howard Lovatt <howard.lovatt at gmail.com>
> wrote:
>
> When the user writes:
>
>     let increment: <T>(T) throws -> T where T: Numeric = { $0 + 1 }
>     increment(1) // 2
>     increment(1.1) // 2.1
>
>
> This means that ‘increment’ is a *value* with a generic function type.
> Presumably you want to pass generic closures as function parameters and
> results too. This is called higher-rank polymorphism and it introduces
> considerable complexity in type checking and code generation.
>
> Compiler issues global struct as above. Then:
>
>     let _int_increment = _Function1__T1__T1__T1__E__Numeric<Int>({ $0 + 1
> })
>     try _int_increment.call(1) // 2
>     let _double_increment = _Function1__T1__T1__T1__E__Numeric<Double>({
> $0 + 1 })
>     try _double_increment.call(1.1) // 2.1
>
>
> What if I do,
>
> let array = [increment]
>
> What is the type of ‘array’?
>
> Slava
>
>
> The more restrictive form that you suggest (I think this is what you mean
> anyway) of only allowed locally, not globally, is easier to name mangle,
> you just need a unique name, nothing about the name needs to be canonical.
> This would be similar to local functions at present and would be useful
> (though I am not sure how many local *generic* functions there are).
>
>
>
>   -- Howard.
>
> On 17 November 2017 at 10:47, Slava Pestov <spestov at apple.com> wrote:
>
>>
>>
>> On Nov 16, 2017, at 3:07 PM, Howard Lovatt via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>> Where I am proposing a change is that if a closure with generic arguments
>> is encountered it is transformed into the equivalent struct and the struct
>> is typed as it currently is (or if there is a better implementation
>> something equivalent to this), therefore zero change to the type system.
>>
>>
>> Since we already have local functions that can capture values and be
>> generic, there’s no need to implement a new mechanism for name mangling or
>> handling of captures.
>>
>>
>> The changes proposed are a transformation into a struct and name
>> mangling, e.g.:
>>
>>     let increment: <T>(T) throws -> T where T: Numeric = { $0 + 1 }
>>     let increment = { <T>(n: T) throws -> T where T: Numeric in n + 1 }
>>     let increment: <T>(T) throws -> T where T: Numeric = { <T>(n: T)
>> throws -> T where T: Numeric in n + 1 }
>>
>>
>> It sounds like what you’re proposing is essentially a new surface syntax
>> for local functions — since a generic closure would not be a first class
>> value, it could not appear anywhere except for the right hand side of a let
>> binding, right?
>>
>> Slava
>>
>
> --
-- Howard.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171119/e5d4f6a5/attachment.html>