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 <[email protected]> wrote: > > On Nov 16, 2017, at 4:38 PM, Howard Lovatt <[email protected]> > 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 <[email protected]> wrote: > >> >> >> On Nov 16, 2017, at 3:07 PM, Howard Lovatt via swift-evolution < >> [email protected]> 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.
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
