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

[Vladimir.S]

On 17.02.2017 20:18, Matthew Johnson via swift-evolution wrote:
> If we do go with the => means pure one option for closures without a
> signature would be something like this: {= $0.pureMethod() }

I feel this will be more clear: {=> in $0.pureMethod() }
i.e. "in" is required to highlight that this is a "modifier" not the 
closure body.
in case you have parameters: {=> x,y in $0.pureMethod(x,y) }


>
> This keeps the closure concise and uses = to indicate purity.  The fact
> that it looks a little bit like assignment is interesting since a pure
> function always has to have a return value.
>
> Sent from my iPad
>
> On Feb 17, 2017, at 10:59 AM, Matthew Johnson via swift-evolution
> <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> 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
>>>>
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>>> 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
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>