> On Feb 17, 2017, at 9:51 AM, André “Zephyz” Videla via swift-evolution
> <swift-evolution@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
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
