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

[Ross O'Brien]

I'm in favour of 'pure' functions, because they're a way of reducing the
repetition of the kind of calculations you might want to perform in
initialisers to convert argument values into property values.

I don't know why "the function must have a return type" is seen as a
requirement, though. There may not be many reasons to call a pure function
without a return type, but requiring a return type, or disallowing inout
parameters, seems arbitrary to me.

On Thu, Feb 16, 2017 at 5:51 PM, Robert Widmann via swift-evolution <
swift-evolution at swift.org> wrote:

>
>
> On Feb 16, 2017, at 12:30 PM, Rien via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> In essence this is about assistance from the compiler that a function
> marked ‘pure’ is indeed pure?
> I.e. an error message should be generated when a function marked as ‘pure’
> is in fact not ‘pure’?
>
> If the answer to both questions is ‘yes’ then -not surprising- its a -1
> from me.
>
> Unless there are other benefits?
>
>
> This feature already exists
> <https://github.com/apple/swift/blob/master/docs/proposals/OptimizerEffects.rst> in
> a certain sense - via the @effects annotation - but is undocumented, highly
> unstable, and does not entail any semantic checking.  I think that at least
> indicates a desire, even if it’s only in the lower-level parts of SIL now,
> to have some way to determine the “purity” of a function to perhaps guide
> an inliner or future block fusion pass.  Perhaps Andrew Trick can speak
> more about the goals of the annotation and whether it would be ready for
> prime time as it were.
>
>
> Regards,
> Rien
>
> Site: http://balancingrock.nl
> Blog: http://swiftrien.blogspot.com
> Github: http://github.com/Balancingrock
> Project: http://swiftfire.nl
>
>
>
>
>
> On 16 Feb 2017, at 18:03, T.J. Usiyan via swift-evolution <
> swift-evolution at swift.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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170216/66d84e88/attachment.html>