This syntax is actually a really clean solution, which can be generalised to arguments and composes well:
A -> B => C -> D vs A -> (@pure B -> C -> D) ------------ Begin Message ------------ Group: gmane.comp.lang.swift.evolution MsgID: <CAGJeWTow9DD9_y86QnVSzfBhKuEbx7dkXrC7_pTorKp=ee_...@mail.gmail.com> 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 <jhull-jaijcdd7...@public.gmane.org> 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-m3fhrko0vlzytjvyw6y...@public.gmane.org> 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 >swift-evolution-m3fhrko0vlzytjvyw6y...@public.gmane.org >https://lists.swift.org/mailman/listinfo/swift-evolution > > > ------------- End Message ------------- _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution