Big +1 from me for the concept, thanks for proposing this, here's some "but"'s that came to my mind after a quick read:
I don't quite like the introduction of a new function arrow, in the end (in my opinion) this is just a more special, more constrained version of a normal function. For me, "pure" feels more like an attribute, describing how a function differs from a "normal" function, see @escaping, etc. (I could imagine having an @total too, but I think the implementation of that is a bit more involved :-)) Have you thought about `@pure`? If so why did you decide against it? Secondly, are they inherited? So if ClassA has a pure function a(), can I override it in subclass ClassB: ClassA to be impure? (I think no) Can I annotate a function in a protocol to force it to be pure? (not sure about this one) - Dennis > On Feb 16, 2017, at 6:03 PM, T.J. Usiyan via swift-evolution > <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 > https://lists.swift.org/mailman/listinfo/swift-evolution
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
