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?
Thanks, Jon > On Feb 16, 2017, at 1:18 PM, T.J. Usiyan <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 https://lists.swift.org/mailman/listinfo/swift-evolution
