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

[David Sweeris]

> 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)
> 
> and 
> 
> 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...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170217/2e08537e/attachment.html>