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

Evolution Pitches
1

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

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