[swift-evolution] [Pitch] Support for pure functions. Part n + 1.
davesweeris at mac.com
Fri Feb 17 12:27:37 CST 2017
> On Feb 17, 2017, at 9:51 AM, André “Zephyz” Videla via swift-evolution <swift-evolution at swift.org> 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 references and therefore cannot create reference cycles even though they are escaping.
> I tend toward using the => sign since it doesn't require a lot of change, it has a nice lightweight syntax and seems different enough from -> .
> The pure keyword in front of the function signature looks like a lot of noise for such a simple concept. And It will only get worse in function signatures.
> see the difference between
> func pureCurryCompose<A, B, C>(f: @pure(B) -> C) -> @pure(@pure(A) -> B) -> (@pure(A) -> C)
> func pureCurryCompose<A, B, C>(f: (B) => C) => ((A) => B) => (A) => C
> The second is easiest to read.
> (of course I would argue that
> func pureCurryCompose<A, B, C>(f: B => C) => (A => B) => (A => C)
> is the most readable of all but I'm too late for that proposal )
I don’t think it’s worth burning an operator for this (especially since the ones that are visually similar to “->” and “=“ are likely to be used by people trying to “wrap” functions or assignment).
I’m also currently -1 on the idea of giving some attributes special syntax… What happens when we decide some other attribute is worth adding? Does, say, “distributive" get to be written as “func * (x:Foo, y:Foo) %> Foo”? How would we denote a function that’s both “pure” and “distributive”? “func * (x:Foo, y:Foo) %~> Foo”? That gets real hard to read (and eats up large swathes of operators) real fast.
- Dave Sweeris
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution