> On Nov 14, 2017, at 7:31 PM, Howard Lovatt via swift-evolution
> <swift-evolution@swift.org> wrote:
>
> You can add generic closures with some name mangling and simple
> transformations, nothing very hard.
>
> The compiler can emit the following for example:
>
> // User writes
> let increment: <T: Numeric>(T) -> T = { $0 + 1 }
> increment(1) // 2
> increment(1.1) // 2.1
>
>
> // Compiler issues
> struct _Generic_Increment<T: Numeric> { // Mangle name
> let increment: (T) -> T = { $0 + 1 }
> }
> _Generic_Increment<Int>().increment(1) // 2
> _Generic_Increment<Double>().increment(1.1) // 2.1
>
> It's plausible that the compiler can do better than the above, but the above
> would be sufficient and is easy to do.
There are several problems here:
- You’re adding a new syntax for a typed pattern with a generic parameter list,
‘let foo: <T> …’. Presumably the right hand side of the assignment has to be a
closure literal. Also such a literal can only be assigned to a let binding and
not passed around as a value, because then you need higher rank types.
- What happens if you use increment as a value without binding generic
parameters? Would that be an error? Eg, ‘let increment2 = increment’.
- What about where clauses?
- Right now, nested types cannot capture values from outer scopes, so your
proposed lowering would need more work in order to be implemented.
I’m not sure what this buys you over local functions. Local functions have the
advantage that they use the same syntax as ordinary functions, whether they are
generic or not. Upon first encountering a local function, someone who has never
seen a local function before will immediately know what it does. You’re
proposing adding some special cases to the grammar to make local functions look
more like closures. This seems to be a step backwards.
Slava
>
> -- Howard.
>
> On 15 November 2017 at 14:02, Matthew Johnson <matt...@anandabits.com
> <mailto:matt...@anandabits.com>> wrote:
>
>
> Sent from my iPhone
>
> On Nov 14, 2017, at 6:56 PM, Howard Lovatt via swift-evolution
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>
>> Having read all the arguments for what to add to local functions it still
>> strikes me as a poor use of engineering resources to fix them (though I do
>> agree they have problems). A better use of resources would be:
>>
>> 1. Deprecate local functions.
>> 2. Allow closures when assigned to a function type to be:
>> 2a. Recursive.
>> 2b. Annotatable with:
>> 2bi. @inline
>> 2bii. @escaping
>> 2c. Generic.
>>
>> That would be a similar engineering effort and give a better short term
>> result of better closures which would be much more widely applicable as well
>> as addressing the issues with local functions.
>
> I believe generic closures would require adding higher rank types to Swift.
> That would be pretty cool but I suspect the engineering effort is at least an
> order of magnitude greater than the changes discussed in this thread.
>
>>
>> It also gives a better long term result of not having to maintain local
>> functions.
>>
>>
>> -- Howard.
>>
>> On 15 November 2017 at 09:08, Alex Lynch via swift-evolution
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> The inference algebra just suggested was enjoyable to read, but is still a
>> new syntax. Which is interesting and deserving of its own proposal. The
>> purpose of this proposal is simply to introduce the existing capture syntax
>> to local functions. Thanks to everyone's feedback pointing out that the
>> `self` reference analysis is a deeper question than initially realized.
>>
>> Alex
>>
>> On Tue, Nov 14, 2017 at 4:36 PM, Mike Kluev via swift-evolution
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> On 14 November 2017 at 21:02, David Hart <da...@hartbit.com
>> <mailto:da...@hartbit.com>> wrote:
>>
>>
>> I’d be very hesitant to introduce this syntax:
>>
>> it’s new syntax, so it comes with a complexity tax (it isn’t naturally
>> obvious what it means for a func to be weak)
>> it’s only sugar for the capture of self
>> it might cover well over 90% of use cases (by my "pessimistic" estimate)...
>> if someone has a quick way to scan and analyse, say, github swift sources we
>> may even know that current percentage number of real life usage.
>> it doesn’t transpose well to local closures
>>
>> the last one - maybe not. follow me:
>>
>> let closure = { [weak self, bar] in ... }
>>
>> which today can be written as:
>>
>> let closure = { [weak self, bar] () -> Int in ... } // full form
>>
>> or as:
>>
>> let closure: () -> Int = { [weak self, bar] in ... } // full form
>>
>> which allows this change:
>>
>> let closure: [weak self, bar] () -> Int = { ... } // full alt form
>>
>> or in alternative form:
>>
>> let closure: weak () -> Int = { [bar] in ... } // short hand form
>>
>> same can be with functions:
>>
>> func fn() -> Int { [weak self, bar] in ... } // full form
>>
>> weak func fn() -> Int { [bar] in ... } // short hand form
>>
>> the two capture attributes will in practice be "close" to each other:
>>
>> weak func fn() {
>> [bar] in
>> ....
>> }
>>
>> and in majority of cases there will be only weak self:
>>
>> weak func fn() {
>> ....
>> }
>>
>> Mike
>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>
>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
