> 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@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 <matt...@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 <flor...@flovilmart.com
>>> <mailto:flor...@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@swift.org <mailto:swift-evolution@swift.org>>, wrote:
>>>>
>>>>> On Feb 17, 2017, at 10:46 AM, David Sweeris via swift-evolution
>>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>>>
>>>>>
>>>>> On Feb 17, 2017, at 08:21, Adrian Zubarev via swift-evolution
>>>>> <swift-evolution@swift.org <mailto:swift-evolution@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@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
