[swift-evolution] [Pitch] Support for pure functions. Part n + 1.

[André “Zephyz” Videla]

> But given the scope capturing nature of closures I was actually wondering if this 'purity' should be applied to closures.
I think It should, pure closure cannot have outside references and therefore cannot create reference cycles even though they are escaping.

I tend toward using the => sign since it doesn't require a lot of change, it has a nice lightweight syntax and seems different enough from -> .
The pure keyword in front of the function signature looks like a lot of noise for such a simple concept. And It will only get worse in function signatures.

see the difference between 

func pureCurryCompose<A, B, C>(f: @pure(B) -> C) -> @pure(@pure(A) -> B) -> (@pure(A) -> C)

and 

func pureCurryCompose<A, B, C>(f: (B) => C) => ((A) => B) => (A) => C

The second is easiest to read.

(of course I would argue that 

func pureCurryCompose<A, B, C>(f: B => C) => (A => B) => (A => C) 

is the most readable of all but I'm too late for that proposal )

> On 17 Feb 2017, at 18:02, Florent Vilmart via swift-evolution <swift-evolution at swift.org> wrote:
> 
> We could do:
> 
> pure let closure = { _-> Else in }
> 
> But given the scope capturing nature of closures I was actually wondering if this 'purity' should be applied to closures.
> 
> After all an inline defined func would do.
> 
> 
> On Feb 17, 2017, 11:59 AM -0500, Matthew Johnson <matthew at anandabits.com>, wrote:
>> How do you suggest a closure indicate its purity? Something like this?  
>> 
>> { pure in $0.property } 
>> 
>>> On Feb 17, 2017, at 10:57 AM, Florent Vilmart <florent at flovilmart.com <mailto:florent at flovilmart.com>> wrote:
>>> 
>>> We were discussing the topic yesterday with others and some suggested adding a pure keyword, for improved readability, just before the function declaration:
>>> 
>>> Ex:
>>> 
>>> pure func(a:Some) -> Else {}
>>> 
>>> 
>>> 
>>> On Feb 17, 2017, 11:51 AM -0500, Matthew Johnson via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>>, wrote:
>>>> 
>>>>> On Feb 17, 2017, at 10:46 AM, David Sweeris via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>>> 
>>>>> 
>>>>> On Feb 17, 2017, at 08:21, Adrian Zubarev via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>>> 
>>>>>> I haven’t yet read all the feedback in this topic but I’d like to throw some bikeshedding of mine into the room. :)
>>>>>> 
>>>>>> How about this?
>>>>>> 
>>>>>> Version 1: func(pure) …
>>>>>> Version 2: func label(…) ~> ReturnType
>>>>> Version 2 is going to upset those who use "~>" as an operator.
>>>>> 
>>>>> As the # of possible attributes grows, having an obvious grouping mechanism for them, like version 1, might be worthwhile simply to help make the list clearer. What about allowing "@(list, of, attributes)" instead of "@list, @of, @attributes”?
>>>> 
>>>> That would be a little bit awkward for attributes that are parameterized.  And if we did do this we should allow the parens to be omitted when there is only one attribute.
>>>> 
>>>>> 
>>>>> - Dave Sweeris
>>>>> _______________________________________________
>>>>> swift-evolution mailing list
>>>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>> 
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> 
> _______________________________________________
> 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/20170217/b116d30a/attachment.html>