> On Feb 17, 2017, at 4:05 PM, Daniel Leping <dan...@crossroadlabs.xyz> wrote: > > I personally like a lot => syntax for several reasons: > 1. Consistent > 2. Enforced return type > > As for the closures, I don't think we need an indication here. If it calls > any impure function or captures a variable from outside - it's impure by > definition. The compiler should decide if a closure can be treated pure. Same > as with throwing.
I’m not sure about this. I would like the ability to syntactically state the intent that a closure is pure, and ideally do so in a way that doesn’t lose the conciseness of the closure (i.e. we shouldn’t have to give up any of the syntactic sugar available for simple closures). A big benefit of allowing us to state intent like this is that it localizes error messages. > > As for the situation with currying (and other compositions), the situation is > a lot more complicated than with rethrows. However, it's still deductible in > compile time with the same mechanism as described above for closures. > > I tend to agree we could use ~> (looks good to me... volatile :)) for the > function type definitions as an "unknown purity". The return type purity > dependence graph can be built automatically at compile time. With this graph > compiler can determine the returned function purity in every place function > is used. > > The use of ~> should of course be limited to argument and return types of > pure functions only. I think there might be a possibility of use in > typealias, but need to think more about it. > > On Fri, 17 Feb 2017 at 22:59 Matthew Johnson via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> On Feb 17, 2017, at 2:52 PM, Jonathan Hull via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> Out of curiosity, what are the benefits to being able to define that a >> closure must be pure as a parameter/type definition, as opposed to defining >> a particular closure to being pure while being passed? What guarantees does >> it give you as the caller of the closure? > > If you only accept pure closures and otherwise meet the criteria of a pure > function then you are pure. If you have a function like that and want to > accept both pure and impure closures and receive the purity of the closure > provided then we need syntax indicating something similar to `rethrows`, but > for purity. > >> >> Thanks, >> Jon >> >> >>> On Feb 16, 2017, at 1:18 PM, T.J. Usiyan <griotsp...@gmail.com >>> <mailto:griotsp...@gmail.com>> wrote: >>> >>> 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 >>> <https://twitter.com/griotspeak/status/832247545325842432> >>> >>> On Thu, Feb 16, 2017 at 4:13 PM, Jonathan Hull <jh...@gbis.com >>> <mailto:jh...@gbis.com>> 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@swift.org <mailto: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 <mailto:swift-evolution@swift.org> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>> >>> >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org <mailto:swift-evolution@swift.org> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
