[swift-evolution] [Pitch] Support for pure functions. Part n + 1.

[James Froggatt]

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_XBg at 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-JAIJCdD7TF0 at 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-m3FHrko0VLzYtjvyW6yDsg at 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-m3FHrko0VLzYtjvyW6yDsg at public.gmane.org
>https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>



------------- End Message -------------