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

Nicolas Fezans nicolas.fezans at gmail.com
Fri Feb 17 11:58:45 CST 2017

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 letters of the pure keyword but just confusing and frightening
for newcomers (BTW __pure exists in GCC if I remember well) whereas
"pure func" is something that people can easily google in case they
need to learn the concept. The different arrows are very compact but
feel a bit like J, which is a language I would not like swift to look

For closure I would rather see it as in this example

[2.0 , 3.0 , 4.0].map(pure {(x: Double)->Double in return x*x})

just pure preceding the closure and it would preceeds "func" in "pure
func". (it could be @pure in both case too)


On Fri, Feb 17, 2017 at 6:36 PM, Adrian Zubarev via swift-evolution
<swift-evolution at swift.org> wrote:
> 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 or
> impure depending on the other function. Doesn’t this imply that -> is
> exactly this pure OR impure function. It’s either or but never both right?
> Otherwise it might lead us to a huge breaking change. A suggestion building
> on top of the arrow syntax we could have:
> pure function: ~>
> impure function: ≈> (That’s a ‘double tilde’)
> pure or impure function: -> (it is as to top and bottom tilde was merged and
> smoothed together)
> --
> Adrian Zubarev
> Sent with Airmail
> Am 17. Februar 2017 um 17:43:21, Matthew Johnson (matthew at anandabits.com)
> schrieb:
> Well sure, but then you have just supplied the type annotation.  I am
> describing a specific scenario where an API can accept a function that is
> pure or a function that is impure and will have the purity of the function
> passed into it.
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

More information about the swift-evolution mailing list