> On Feb 17, 2017, at 4:17 PM, Daniel Leping <dan...@crossroadlabs.xyz> 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() }
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 <matt...@anandabits.com
> <mailto:matt...@anandabits.com>> wrote:
>> On Feb 17, 2017, at 4:05 PM, Daniel Leping <dan...@crossroadlabs.xyz
>> <mailto:dan...@crossroadlabs.xyz>> 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
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>> On Feb 17, 2017, at 2:52 PM, Jonathan Hull via swift-evolution
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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 <griotsp...@gmail.com
>>>> <mailto:griotsp...@gmail.com>> 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
>>>> <https://twitter.com/griotspeak/status/832247545325842432>
>>>>
>>>> On Thu, Feb 16, 2017 at 4:13 PM, Jonathan Hull <jh...@gbis.com
>>>> <mailto:jh...@gbis.com>> 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
>>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>>>
>>>>> # Pure Functions
>>>>>
>>>>> * Proposal:
>>>>> [SE-NNNN](https://github.com/apple/swift-evolution/blob/master/proposals/NNNN-name.md
>>>>>
>>>>> <https://github.com/apple/swift-evolution/blob/master/proposals/NNNN-name.md>)
>>>>> * Author(s): [TJ Usiyan](https://github.com/griotspeak
>>>>> <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
>>>>> 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 <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
