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

> On Feb 20, 2017, at 2:56 PM, David Sweeris via swift-evolution > wrote: > >> >> On Feb 20, 2017, at 2:50 PM, Michel Fortin via swift-evolution >> wrote: >> >>> Le 20 févr. 2017 à 14:45, Matthew Johnson a écrit

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

> On Feb 21, 2017, at 9:38 PM, Michel Fortin wrote: > >> Le 21 févr. 2017 à 22:05, Matthew Johnson a écrit : >> Le 20 févr. 2017 à 12:17, Matthew Johnson a écrit : > e) Generic Containers: >

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

> Le 21 févr. 2017 à 22:05, Matthew Johnson a écrit : > >>> Le 20 févr. 2017 à 12:17, Matthew Johnson a écrit : >>> e) Generic Containers: Generic containers that impose requirements on their elements will pose some additional

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

> On Feb 21, 2017, at 8:57 PM, Michel Fortin via swift-evolution > wrote: > > (this was accidentally sent off-list, reposting here a day later) And this was my reply. > >> Le 20 févr. 2017 à 12:17, Matthew Johnson a écrit : >> >>> e)

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

(this was accidentally sent off-list, reposting here a day later) > Le 20 févr. 2017 à 12:17, Matthew Johnson a écrit : > >> e) Generic Containers: >> Generic containers that impose requirements on their elements will pose some >> additional problems, for instance:

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

> On Feb 16, 2017, at 09:03, T.J. Usiyan via swift-evolution > wrote: > > # Pure Functions > > * Proposal: > [SE-](https://github.com/apple/swift-evolution/blob/master/proposals/-name.md) > * Author(s): [TJ Usiyan](https://github.com/griotspeak) > * Status:

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

> On Feb 20, 2017, at 6:54 PM, Michel Fortin wrote: > >> >> Le 20 févr. 2017 à 18:02, Matthew Johnson a écrit : >> >> >>> On Feb 20, 2017, at 4:50 PM, Michel Fortin wrote: >>> Le 20 févr. 2017 à 14:45,

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

> Le 20 févr. 2017 à 18:02, Matthew Johnson a écrit : > > >> On Feb 20, 2017, at 4:50 PM, Michel Fortin wrote: >> >>> Le 20 févr. 2017 à 14:45, Matthew Johnson a écrit : >>> On Feb 20, 2017, at 1:42 PM,

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

> Le 20 févr. 2017 à 17:56, David Sweeris a écrit : > > Could we only infer purity for one “level”? As a technical limitation rather > than part of the language spec, to be removed at some later date when we have > time to implement the diagnostic logic? So in your

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

> On Feb 20, 2017, at 4:50 PM, Michel Fortin > wrote: > >> Le 20 févr. 2017 à 14:45, Matthew Johnson > > a écrit : >> >>> >>> On Feb 20, 2017, at 1:42 PM, Michel Fortin

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

> On Feb 20, 2017, at 2:50 PM, Michel Fortin via swift-evolution > wrote: > >> Le 20 févr. 2017 à 14:45, Matthew Johnson a écrit : >> >>> >>> On Feb 20, 2017, at 1:42 PM, Michel Fortin wrote: >>> Le 20 févr.

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

> Le 20 févr. 2017 à 14:45, Matthew Johnson a écrit : > >> >> On Feb 20, 2017, at 1:42 PM, Michel Fortin wrote: >> >>> Le 20 févr. 2017 à 14:23, Charles Srstka a écrit >>> : >>> >>> I’m not sure how I feel about

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

> On Feb 20, 2017, at 1:42 PM, Michel Fortin wrote: > >> Le 20 févr. 2017 à 14:23, Charles Srstka a écrit : >> >> I’m not sure how I feel about that, since it hamstrings the ability to >> improve APIs in a lot of ways without breaking

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

> Le 20 févr. 2017 à 14:23, Charles Srstka a écrit : > > I’m not sure how I feel about that, since it hamstrings the ability to > improve APIs in a lot of ways without breaking backwards compatibility. A > quick example off the top of my head would be all the Cocoa

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

> On Feb 20, 2017, at 11:23 AM, Charles Srstka via swift-evolution > wrote: > >> On Feb 20, 2017, at 12:53 PM, Matthew Johnson > > wrote: >> >>> >>> On Feb 20, 2017, at 12:42 PM, Charles Srstka via

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

> On Feb 20, 2017, at 1:23 PM, Charles Srstka wrote: > >> On Feb 20, 2017, at 12:53 PM, Matthew Johnson > > wrote: >> >>> >>> On Feb 20, 2017, at 12:42 PM, Charles Srstka via swift-evolution >>>

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

> Le 20 févr. 2017 à 13:42, Charles Srstka a écrit : > >> On Feb 20, 2017, at 10:55 AM, Michel Fortin via swift-evolution >> wrote: >> >> a) Structs/Locals: >> Structs and local variables behave similarly. You can access `let` and `var` >>

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

> On Feb 20, 2017, at 12:53 PM, Matthew Johnson wrote: > >> >> On Feb 20, 2017, at 12:42 PM, Charles Srstka via swift-evolution >> > wrote: >> >>> On Feb 20, 2017, at 10:55 AM, Michel Fortin via

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

> On Feb 20, 2017, at 12:42 PM, Charles Srstka via swift-evolution > wrote: > >> On Feb 20, 2017, at 10:55 AM, Michel Fortin via swift-evolution >> > wrote: >> >> a) Structs/Locals: >> Structs and local

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

> On Feb 20, 2017, at 10:42 AM, Charles Srstka via swift-evolution > wrote: > >> On Feb 20, 2017, at 10:55 AM, Michel Fortin via swift-evolution >> > wrote: >> >> a) Structs/Locals: >> Structs and local

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

> On Feb 20, 2017, at 10:55 AM, Michel Fortin via swift-evolution > wrote: > > a) Structs/Locals: > Structs and local variables behave similarly. You can access `let` and `var` > properties and mutate the later. What if the struct contains class ivars, including

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

> On Feb 20, 2017, at 10:55 AM, Michel Fortin via swift-evolution > wrote: > > (continuing my thoughts from my previous post) > > I think a definition of `pure` that'd work well for Swift is one that is > based on forbidding dereferencing of pointers (including

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

> On Feb 20, 2017, at 10:24 AM, Michel Fortin via swift-evolution > wrote: > > Le 20 févr. 2017 à 1:19, David Sweeris a écrit : >> >> On Feb 19, 2017, at 21:19, Xiaodi Wu wrote: >> >>> This is very, very interesting.

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

(continuing my thoughts from my previous post) I think a definition of `pure` that'd work well for Swift is one that is based on forbidding dereferencing of pointers (including object references) so that all you ever deal with is value semantics. With some exceptions for dereferencing when

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

Le 20 févr. 2017 à 1:19, David Sweeris a écrit : > > On Feb 19, 2017, at 21:19, Xiaodi Wu wrote: > >> This is very, very interesting. Thank you so much for the text. >> >> If I understand your take correctly, the benefits of `pure` in Swift would >>

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

The message about D was from me. I'm actually quite familiar with D so I'll try to summarize it's take on purity here. # Pure in D D has the keyword `pure`, and the compiler enforces purity constraints. There is basically two types of pure functions: strongly pure ones and weakly pure one,

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

I don't know very much about this topic, so I won't pretend that I have strong feelings about Michel's questions, but they are undeniably important and undoubtedly only one of many. Before we get to any syntactic bikeshedding, can the proponents of this feature write up a comparative summary to

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

I'm going to update the draft with points addressed here and the twitter conversation. There have been quite a few implications to consider pointed out. This feature is not 'for' the compiler as much as it is for humans writing code, but I will address that in the update. On Sun, Feb 19, 2017 at

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

> On Feb 19, 2017, at 11:47, Michel Fortin via swift-evolution > wrote: > > 7. Is it desirable that the optimizer sometime take the pure attribute to > heart to combine multiple apparently redundant calls into a single one? Or is > pure not intended to be usable

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

> On Feb 19, 2017, at 1:47 PM, Michel Fortin via swift-evolution > wrote: > > I'm a bit disappointed to see this discussion bikeshedding the syntax without > clarifying much the semantics. Here's a few question of semantic nature. +1. I think the syntactic

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

I'm a bit disappointed to see this discussion bikeshedding the syntax without clarifying much the semantics. Here's a few question of semantic nature. The base principle of a pure function is that it has no side effects. But it's quite clear that at least some side effects will need to be

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

> On 17 Feb 2017, at 23:30, Matthew Johnson via swift-evolution > wrote: > > >> On Feb 17, 2017, at 4:17 PM, Daniel Leping wrote: >> >> I don't think I can (fully) agree with you, because a closure purity is not >> something you

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

I might(?) agree with others that `constexpr` might overlap but be ultimately different from `pure`. However, to me `constexpr` is more interesting because it would provide a potential macro language. As for syntax, while I think that matters less, I suspect trying to find why code isn't working

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

Second is better, but still looks ugly (no offense). I personally am totally ok with auto determination for most cases. Explicit case doesn't sound to me so widely used. I agree an explicit form might be of use in some rare scenarios and as long there is a possibility to define the purity (even in

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

> On Feb 17, 2017, at 4:17 PM, Daniel Leping wrote: > > I don't think I can (fully) agree with you, because a closure purity is not > something you "define". It's rather what you use inside. Though I totally > understand your concern and a wish to have localized

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

I don't think I can (fully) agree with you, because a closure purity is not something you "define". It's rather what you use inside. Though I totally understand your concern and a wish to have localized errors. However, I think it's totally consistent if you use a full form in a way: { (a) => B

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

> On Feb 17, 2017, at 4:05 PM, Daniel Leping 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

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

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

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

> On Feb 17, 2017, at 2:52 PM, Jonathan Hull via swift-evolution > 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

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

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? Thanks, Jon > On Feb 16,

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

There shouldn't be a need for a third arrow with regard to purity. Impure encompasses pure in that there is simply no guarantee of purity with an impure function. You should be able to use a pure function in place of an impure function without any issue whatsoever. On Fri, Feb 17, 2017 at 1:35

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

I'm really not sold about the ~> operator, as it would be easy to miss. Swift is known and loved for the expressiveness of the language, using that operator doesn't help with that. On another hand, I agree that this is the sexiest, less intrusive solution. On 17 févr. 2017 13:36 -0500, Adrian

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

That autocorrection sometimes :/ Purity could easily be expressed through the arrow, plus it enforces you to have a return type (other than Void). --  Adrian Zubarev Sent with Airmail Am 17. Februar 2017 um 19:27:12, Adrian Zubarev (adrian.zuba...@devandartist.com) schrieb: Purity could be

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

> On Feb 17, 2017, at 9:51 AM, André “Zephyz” Videla via swift-evolution > wrote: > >> But given the scope capturing nature of closures I was actually wondering if >> this 'purity' should be applied to closures. > I think It should, pure closure cannot have outside

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

Who said that pure functions should be newcomer friendly? Swift attributes are way at the end of the swift’s book. Using the -> arrow at first won’t break anything. If one would optimize some functions by annotating them to be pure, the change to something like ~> would be really easy. IMHO

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

Just let @pure func foo(_ f: (Int) -> Int) -> Int be the same as those two combined: @pure func foo(_ f: @pure (Int) -> Int) -> Int func foo(_ f: (Int) -> Int) -> Int No need for anything like “re-pure” or ≃>. ​ ___ swift-evolution mailing list

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

Exactly, there is none. What I was trying to describe is that -> would become the conditional operator that could swallow purity and impurity. However if one would want to be explicit about purity, you’d have to use ~> instead. --  Adrian Zubarev Sent with Airmail Am 17. Februar 2017 um

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

I do not see the rationale behind marking impure functions explicitly. The useful property is to be pure, in case a function is impure or it's status is unknown you just have to assume the worse, i.e. that it is impure. The arrow proposals -> vs. ~> vs. => are not really much shorter than the 4

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

On 17.02.2017 20:18, Matthew Johnson via swift-evolution wrote: If we do go with the => means pure one option for closures without a signature would be something like this: {= $0.pureMethod() } I feel this will be more clear: {=> in $0.pureMethod() } i.e. "in" is required to highlight that

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

> But given the scope capturing nature of closures I was actually wondering if > this 'purity' should be applied to closures. I think It should, pure closure cannot have outside references and therefore cannot create reference cycles even though they are escaping. I tend toward using the =>

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

That problem could be solved with the combining tilde, however it isn’t easy, because it’s simply not easy to type. If ~> would describe the pure function and -> an impure function then the combination of both would be ≃>. One thing I noticed, you said that the function itself will become pure

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

If we do go with the => means pure one option for closures without a signature would be something like this: {= $0.pureMethod() } This keeps the closure concise and uses = to indicate purity. The fact that it looks a little bit like assignment is interesting since a pure function always has

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

Another usecase would be for the type aliases: typealias PureFunc = pure (Some)->Else Or pure typealias PureFunc = (Some)->Else I'm not sure where the keyword should stand On Feb 17, 2017, 12:03 PM -0500, Matthew Johnson via swift-evolution , wrote: > > > On Feb

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

We could do: pure let closure = { _-> Else in } But given the scope capturing nature of closures I was actually wondering if this 'purity' should be applied to closures. After all an inline defined func would do. On Feb 17, 2017, 11:59 AM -0500, Matthew Johnson ,

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

How do you suggest a closure indicate its purity? Something like this? { pure in $0.property } > On Feb 17, 2017, at 10:57 AM, Florent Vilmart wrote: > > We were discussing the topic yesterday with others and some suggested adding > a pure keyword, for improved

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

> On Feb 17, 2017, at 10:55 AM, David Sweeris wrote: > > > On Feb 17, 2017, at 08:49, Matthew Johnson > wrote: > >> >>> On Feb 17, 2017, at 10:46 AM, David Sweeris via swift-evolution >>>

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

We were discussing the topic yesterday with others and some suggested adding a pure keyword, for improved readability, just before the function declaration: Ex: pure func(a:Some) -> Else {} On Feb 17, 2017, 11:51 AM -0500, Matthew Johnson via swift-evolution ,

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

> On Feb 17, 2017, at 08:49, Matthew Johnson wrote: > > >> On Feb 17, 2017, at 10:46 AM, David Sweeris via swift-evolution >> wrote: >> >> >> On Feb 17, 2017, at 08:21, Adrian Zubarev via swift-evolution >>

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

> On Feb 17, 2017, at 10:46 AM, David Sweeris via swift-evolution > wrote: > > > On Feb 17, 2017, at 08:21, Adrian Zubarev via swift-evolution > > wrote: > >> I haven’t yet read all the feedback in this

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

> On Feb 17, 2017, at 08:21, Adrian Zubarev via swift-evolution > wrote: > > I haven’t yet read all the feedback in this topic but I’d like to throw some > bikeshedding of mine into the room. :) > > How about this? > > Version 1: func(pure) … > Version 2: func

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

> On Feb 17, 2017, at 10:33 AM, Adrian Zubarev > wrote: > > Regardless the issue you described with rethrows couldn’t we simply > explicitly tell the compiler the closures type which would include the pure > arrow? > > let _: (T) ~> SomeType = { … } > >

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

> On Feb 17, 2017, at 7:37 AM, David Hart wrote: > > On 17 Feb 2017, at 08:59, Nicolas Fezans via swift-evolution > > wrote: > >> > Not only that, but even if you pass a value type as a parameter, that >> > value

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

Regardless the issue you described with rethrows couldn’t we simply explicitly tell the compiler the closures type which would include the pure arrow? let _: (T) ~> SomeType = { … } That is similar to the behavior we now have with IUOs. (let myView: UIView = self.view inside UIViewController

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

I haven’t yet read all the feedback in this topic but I’d like to throw some bikeshedding of mine into the room. :) How about this? Version 1: func(pure) … Version 2: func label(…) ~> ReturnType --  Adrian Zubarev Sent with Airmail Am 17. Februar 2017 um 17:16:49, Anton Zhilin via

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

I didn’t mean to emphasize any specific syntax. I’m fine with either @const, @constexpr, @pure or =>. Anyway, I see no reason why generic functions shouldn’t be supported in any of the suggested models. 2017-02-17 19:08 GMT+03:00 Abe Schneider : +1. I think this is a

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

2017-02-17 17:13 GMT+03:00 T.J. Usiyan : It is my opinion that you are describing an entirely different, and > somewhat orthogonal, feature. I would like the feature that you describe. > Constant expressions are powerful and open up quite a few optimizations. > What

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

+1. I think this is a great idea. As I was following this thread, I was wondering if someone might suggest the C++ constexpr syntax. Would this support generics? E.g. could you do: @constepxr func foo(a:S, b:S) { return a+b } and have that be done at compile time? While this

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

+1 for pure functions +1 for combining them with constexpr -1 for the syntax originally proposed +1 for pure or @pure keywords (before func and before a closure opening { ) One thing is probably worth considering if pure functions and closures are combined with constexpr and evaluated at

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

> On Feb 16, 2017, at 3:18 PM, T.J. Usiyan via swift-evolution > wrote: > > I am ok with a keyword but `pure` in front of func doesn't work well with > inline closures. The `=>` function arrow syntax is a clever way to avoid making pure functions heaver

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

Anton, It is my opinion that you are describing an entirely different, and somewhat orthogonal, feature. I would like the feature that you describe. Constant expressions are powerful and open up quite a few optimizations. What constexpr addresses is not purity, at the heart of it. Pure

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

> On 17 Feb 2017, at 08:59, Nicolas Fezans via swift-evolution > wrote: > > > Not only that, but even if you pass a value type as a parameter, that value > > type might have reference types as ivars. > > I think that arguments passed to a pure function shall be

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

My vision of “pure” functions was the following: 1. Compiler automatically marks all functions and expressions as pure, wherever possible - We should be interested not in “Haskell-ish pure” functions, but in “computable during compilation” functions - Therefore I prefer to

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

I like the idea of having pure functions in Swift, but my first thought is; should we have to declare it at all? Is it not easier to just have the compiler automatically flag a function as pure or not? With that in mind we don't need any new syntax, but a simple @pure attribute should be

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 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:

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 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:

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

> Not only that, but even if you pass a value type as a parameter, that value type might have reference types as ivars. I think that arguments passed to a pure function shall be checked against containing such references or objects that contains such references themselves: I guess that this check

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

On Feb 16, 2017, at 1:27 PM, Sean Heber via swift-evolution wrote: > > Doesn’t this break down if you can pass a reference as a parameter to a pure > function? If that’s not allowed, I guess I must have missed it. Also this > seems to require the function has a

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

I'm just going to point out to the documentation about pure functions in the D language which has an unusual but very practical take on enforcing purity. It's interesting, and it might also provide a list for things that might need be addressed in this proposal.

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

> On Feb 16, 2017, at 18:00, Slava Pestov wrote: > > >>> On Feb 16, 2017, at 5:15 PM, David Sweeris via swift-evolution >>> wrote: >>> >>> >>> On Feb 16, 2017, at 3:13 PM, David Hart via swift-evolution >>> wrote:

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

> On Feb 16, 2017, at 5:15 PM, David Sweeris via swift-evolution > wrote: > > >> On Feb 16, 2017, at 3:13 PM, David Hart via swift-evolution >> > wrote: >> >> Now that I've thought more about it, I have

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

> On Feb 16, 2017, at 3:13 PM, David Hart via swift-evolution > wrote: > > Now that I've thought more about it, I have a question. Escaping/unescaping > is an important concept to have in the language: if the API provider makes > the promise that a closure is

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

> On Feb 16, 2017, at 9:51 AM, Robert Widmann via swift-evolution > wrote: > > > >> On Feb 16, 2017, at 12:30 PM, Rien via swift-evolution >> wrote: >> >> In essence this is about assistance from the compiler that a function marked >>

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

Now that I've thought more about it, I have a question. Escaping/unescaping is an important concept to have in the language: if the API provider makes the promise that a closure is non-escaping, the API client doesn't have to worry about the closure capturing variables and creating strong

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

I think discovering them is not the problem, the question is if you really want them to be annotated pro-actively by the compiler - I don't think so. Your comparison with @escape is both right and wrong :) It's wrong in the sense that @escaping is a relaxing attribute while @pure is a

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

> On Feb 16, 2017, at 3:25 PM, Sean Heber via swift-evolution > wrote: > > Couldn’t pure functions be discovered by the compiler like how the compiler > already discovers an escaping vs. non-escaping function? Then perhaps pure > only needs to be an attribute on

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

> On Feb 16, 2017, at 10:24 PM, David Sweeris wrote: > > >> On Feb 16, 2017, at 13:10, Dennis Weissmann via swift-evolution >> wrote: >> >> Secondly, are they inherited? So if ClassA has a pure function a(), can I >> override it in subclass

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

Couldn’t pure functions be discovered by the compiler like how the compiler already discovers an escaping vs. non-escaping function? Then perhaps pure only needs to be an attribute on closure parameter - just like how @escaping works? l8r Sean > On Feb 16, 2017, at 3:18 PM, T.J. Usiyan via

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

> On Feb 16, 2017, at 13:10, Dennis Weissmann via swift-evolution > wrote: > > Secondly, are they inherited? So if ClassA has a pure function a(), can I > override it in subclass ClassB: ClassA to be impure? (I think no) I would agree. IIUC, the "pureness" of A's

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

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 wrote: >

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

+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'

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

Big +1 from me for the concept, thanks for proposing this, here's some "but"'s that came to my mind after a quick read: I don't quite like the introduction of a new function arrow, in the end (in my opinion) this is just a more special, more constrained version of a normal function. For me,

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

I held your opinion, although not terribly steadfast. Joe Groff convinced me that I was being pedantic with "'inout' is 'value goes in, value-prime goes out'" and the fact that it composes; you could use pure `+=` on a local value inside another pure function. The specific details of `inout` mean

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

Thank you everyone. Since there does some to be interest, I have created a gist with some updates based on feedback. I have only incorporated the quickly integratabtle bits, so far. https://gist.github.com/griotspeak/31445ddcdba44bb8de599be6c9a93bd1 On Thu, Feb 16, 2017 at 3:03 PM, Nicolas

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

By its classic definition, a function that has inout parameters is not pure. So, again by classic definition, it should have a return value to have any use. But things can quickly get murky if we try to enhance and extend the meaning of pure. Then it becomes important to see at what level of

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

> If it mutates whatever the input is referencing, it would have a side-effect which makes it "not pure" (for my understanding of what “pure” means). I am not really sure of it (I have not played around with it until now) but I don't think that this is an issue with the swift inout, cf.

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

> On Feb 16, 2017, at 11:27 AM, Sean Heber via swift-evolution > wrote: > > Doesn’t this break down if you can pass a reference as a parameter to a pure > function? If that’s not allowed, I guess I must have missed it. Also this > seems to require the function has

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

This looks cool. Quick nit-pick inline: > On 16 Feb 2017, at 18:03, T.J. Usiyan via swift-evolution > wrote: > > # Pure Functions > > * Proposal: > [SE-](https://github.com/apple/swift-evolution/blob/master/proposals/-name.md > >

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

Doesn’t this break down if you can pass a reference as a parameter to a pure function? If that’s not allowed, I guess I must have missed it. Also this seems to require the function has a return value. I suppose generally a pure function without a return value wouldn’t make much sense - unless

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

+1 I think it's a very interesting proposal and here is why: - It improve readability by expressing intent. For example the difference between those two function, just by their signature, is obvious: func update(_ m: Class) -> Class and func update(_ m: Class) => Class The first one mutates

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

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.

  1   2   >