> On 17 Feb 2017, at 23:30, Matthew Johnson via swift-evolution
> <[email protected]> wrote:
>
>
>> On Feb 17, 2017, at 4:17 PM, Daniel Leping <[email protected]> wrote:
>>
>> I don't think I can (fully) agree with you, because a closure purity is not
>> something you "define". It's rather what you use inside. Though I totally
>> understand your concern and a wish to have localized errors.
>>
>> However, I think it's totally consistent if you use a full form in a way:
>>
>> { (a) => B in
>> return a.toB()
>> }
>>
>> What I mean is that short form can auto determine. If you want to be
>> explicit... use the long form.
>>
>> Would this work for you, @Matthew?
>
> What I am saying is that I don’t think I should have to use the entire long
> form just to specify it’s a pure closure. Something like the following would
> be acceptable:
>
> {= $0.some.pure.expression() }
> or
> {=> $0.some.pure.expression() }
Or:
{ x => x.some.pure.expression() }
> But I don’t want to be required to write out a name for the arguments and a
> return type for single expression closures like this.
>
>>
>> On Sat, 18 Feb 2017 at 0:09 Matthew Johnson <[email protected]> wrote:
>>>> On Feb 17, 2017, at 4:05 PM, Daniel Leping <[email protected]>
>>>> wrote:
>>>>
>>>> I personally like a lot => syntax for several reasons:
>>>> 1. Consistent
>>>> 2. Enforced return type
>>>>
>>>> As for the closures, I don't think we need an indication here. If it calls
>>>> any impure function or captures a variable from outside - it's impure by
>>>> definition. The compiler should decide if a closure can be treated pure.
>>>> Same as with throwing.
>>>
>>> I’m not sure about this. I would like the ability to syntactically state
>>> the intent that a closure is pure, and ideally do so in a way that doesn’t
>>> lose the conciseness of the closure (i.e. we shouldn’t have to give up any
>>> of the syntactic sugar available for simple closures). A big benefit of
>>> allowing us to state intent like this is that it localizes error messages.
>>>
>>>>
>>>> As for the situation with currying (and other compositions), the situation
>>>> is a lot more complicated than with rethrows. However, it's still
>>>> deductible in compile time with the same mechanism as described above for
>>>> closures.
>>>>
>>>> I tend to agree we could use ~> (looks good to me... volatile :)) for the
>>>> function type definitions as an "unknown purity". The return type purity
>>>> dependence graph can be built automatically at compile time. With this
>>>> graph compiler can determine the returned function purity in every place
>>>> function is used.
>>>>
>>>> The use of ~> should of course be limited to argument and return types of
>>>> pure functions only. I think there might be a possibility of use in
>>>> typealias, but need to think more about it.
>>>>
>>>>> On Fri, 17 Feb 2017 at 22:59 Matthew Johnson via swift-evolution
>>>>> <[email protected]> wrote:
>>>>
>>>>> On Feb 17, 2017, at 2:52 PM, Jonathan Hull via swift-evolution
>>>>> <[email protected]> wrote:
>>>>>
>>>>> Out of curiosity, what are the benefits to being able to define that a
>>>>> closure must be pure as a parameter/type definition, as opposed to
>>>>> defining a particular closure to being pure while being passed? What
>>>>> guarantees does it give you as the caller of the closure?
>>>>
>>>> If you only accept pure closures and otherwise meet the criteria of a pure
>>>> function then you are pure. If you have a function like that and want to
>>>> accept both pure and impure closures and receive the purity of the closure
>>>> provided then we need syntax indicating something similar to `rethrows`,
>>>> but for purity.
>>>>
>>>>>
>>>>> Thanks,
>>>>> Jon
>>>>>
>>>>>
>>>>>> On Feb 16, 2017, at 1:18 PM, T.J. Usiyan <[email protected]> wrote:
>>>>>>
>>>>>> I am ok with a keyword but `pure` in front of func doesn't work well
>>>>>> with inline closures.
>>>>>>
>>>>>> A few people talked through many of these issues starting with this
>>>>>> tweet. https://twitter.com/griotspeak/status/832247545325842432
>>>>>>
>>>>>> On Thu, Feb 16, 2017 at 4:13 PM, Jonathan Hull <[email protected]> wrote:
>>>>>> +1 for the idea of pure functions in swift. Seems like it would enable
>>>>>> a lot of good optimizations (in some cases even just evaluating the
>>>>>> function at compile time).
>>>>>>
>>>>>> -1 on the specific notation. I would much rather just put the word
>>>>>> ‘pure’ in front of ‘func’, the same way we put ‘mutating' in front of
>>>>>> mutating functions… it seems to me like these are part of the same
>>>>>> family.
>>>>>>
>>>>>> I agree we should allow inout.
>>>>>>
>>>>>> Thanks,
>>>>>> Jon
>>>>>>
>>>>>>> On Feb 16, 2017, at 9:03 AM, T.J. Usiyan via swift-evolution
>>>>>>> <[email protected]> wrote:
>>>>>>>
>>>>>>> # Pure Functions
>>>>>>>
>>>>>>> * Proposal:
>>>>>>> [SE-NNNN](https://github.com/apple/swift-evolution/blob/master/proposals/NNNN-name.md)
>>>>>>> * Author(s): [TJ Usiyan](https://github.com/griotspeak)
>>>>>>> * Status: **Awaiting review**
>>>>>>> * Review manager: TBD
>>>>>>>
>>>>>>> ## Introduction
>>>>>>>
>>>>>>> Some functions are, essentially, only meant to be transformations of
>>>>>>> their input and–as such–do not and should not reference any variables
>>>>>>> other than those passed in. These same functions are not meant to have
>>>>>>> any effects other than the aforementioned transformation of input.
>>>>>>> Currently, Swift cannot assist the developer and confirm that any given
>>>>>>> function is one of these 'pure' functions. To facilitate this, this
>>>>>>> proposal adds syntax to signal that a function is 'pure'.
>>>>>>>
>>>>>>> 'pure', in this context, means:
>>>>>>> 1. The function must have a return value
>>>>>>> 1. This function can only call other pure functions
>>>>>>> 1. This function cannot access/modify global or static variables.
>>>>>>>
>>>>>>> ## Motivation
>>>>>>>
>>>>>>> Consider the following example where `_computeNullability(of:)` is
>>>>>>> meant to create its output solely based on the provided recognizer.
>>>>>>>
>>>>>>> ```
>>>>>>> class Recognizer {
>>>>>>> var nullabilityMemo: Bool?
>>>>>>> var isNullable: Bool {
>>>>>>> func _computeNullability(of recognizer: Recognizer) ->
>>>>>>> Bool {…}
>>>>>>> if let back = nullabilityMemo {
>>>>>>> return back
>>>>>>> } else {
>>>>>>> let back = _computeNullability(of: self)
>>>>>>> nullabilityMemo = back
>>>>>>> return back
>>>>>>> }
>>>>>>> }
>>>>>>> }
>>>>>>> ```
>>>>>>> if `_computeNullability(of:)` is recursive at all, there exists a real
>>>>>>> potential to accidentally reference `self` in its body and the mistake,
>>>>>>> depending on circumstance, can be terribly subtle. Converting
>>>>>>> `_computeNullability(of:)` to a `static` function is an option but
>>>>>>> obfuscates the fact that it is *only* to be called within `isNullable`.
>>>>>>>
>>>>>>>
>>>>>>> ## Proposed solution
>>>>>>>
>>>>>>> Given the ability to indicate that `_computeNullability(of:)` is a
>>>>>>> 'pure' function, the developer gains assurance from the tooling that it
>>>>>>> doesn't reference anything or cause any side effects.
>>>>>>>
>>>>>>>
>>>>>>> ```
>>>>>>> class Recognizer {
>>>>>>> var nullabilityMemo: Bool?
>>>>>>> var isNullable: Bool {
>>>>>>> pfunc _computeNullability(of recognizer: Recognizer) ->
>>>>>>> Bool {…}
>>>>>>> if let back = nullabilityMemo {
>>>>>>> return back
>>>>>>> } else {
>>>>>>> let back = _computeNullability(of: self)
>>>>>>> nullabilityMemo = back
>>>>>>> return back
>>>>>>> }
>>>>>>> }
>>>>>>> }
>>>>>>> ```
>>>>>>>
>>>>>>> ## Detailed design
>>>>>>>
>>>>>>> This proposal introduces a new annotation `=>`, which is to be accepted
>>>>>>> everywhere `->` currently is. Members created using this kewyord must
>>>>>>> follow the rules listed in the introduction.
>>>>>>>
>>>>>>> ## Impact on existing code
>>>>>>>
>>>>>>> This is an additive feature unless alternative 2 is chosen and, as
>>>>>>> such, should not require an effect on existing code. It could be used
>>>>>>> to annotate closures accepted by methods in the standard library such
>>>>>>> as `map`, `filter`, and `reduce`. While this would fit well with their
>>>>>>> typical use, such a change is not necessarily part of this proposal.
>>>>>>>
>>>>>>> ## Alternatives considered
>>>>>>>
>>>>>>> It should be noted that neither of these alternatives can remain
>>>>>>> consistent for inline closures.
>>>>>>> 1. keyword `pfunc` (pronounciation: pifəŋk) for 'pure' functions.
>>>>>>> 2. `proc` keyword for 'impure' functions and 'func' for 'pure'
>>>>>>> functions. This would be a massively source breaking change and, as
>>>>>>> such, is unlikely to have any feasibility. It is, however, the most
>>>>>>> clean semantically, in my opinion.
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> swift-evolution mailing list
>>>>>>> [email protected]
>>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> swift-evolution mailing list
>>>>> [email protected]
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> [email protected]
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
