[swift-evolution] Proposal proposal: @pure keyword

Sat Jan 9 07:06:04 CST 2016

Hi 品雪,

As I understand Howard's intentions @pure and @impure are just antonyms,
like true versus false. The important distinction is that if we only had a
@pure keyword then functions are allowed to be impure by default, which is
easier for existing code and probably beginner programmers. Functions are
not checked for purity unless annotated.

C and Objective-C may be able to be marked as pure in future, but I think
it's too difficult to do so at the moment. It's probably the case that
there will be some kind of import attribute that could allow c functions to
be marked as pure for the standard library, however I doubt there will be
any automated checking.

"no-side-effects" is essentially the same. It's mainly a matter of defining
what side-effects are and are not allowed. Side-effects could mean that it
doesn't take any processor time, or it doesn't change registers, or cannot
abort execution, allocate memory, etc.

Andrew

On Sat, Jan 9, 2016 at 8:59 PM, 品雪 <pinxue at gmail.com> wrote:

> So what's the semantic difference between @pure and @impure type?
>
> "c and objective-c would not be marked as pure." It sounds like pure
> swift.
>
> "Pure functions can be safely removed by the optimizer if their result is
> not used. " It sounds like no-side-effects or immutable.
>
>
> On Sat, Jan 9, 2016 at 5:14 PM, Howard Lovatt via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>> Comment in-line below.
>>
>> On 9 Jan 2016, at 8:04 PM, Andrew Bennett <cacoyi at gmail.com> wrote:
>>
>> That would be nice, although I'm not sure how practical that is in
>> current swift usage. I imagine it would require a lot of changes to
>> existing code and libraries.
>>
>>
>> Not sure how hard this would be or if a migration tool and enhanced Obj-C
>> importer would be good enough.
>>
>> Is a method impure if it uses self? I suppose it could be. I guess self
>> is an inout parameter. I presume an inout parameter is a known expected
>> side-effect.
>>
>>
>> If it doesn’t change self then it is pure.
>>
>> Closures would probably be the largest impact if things were pure by
>> default.
>>
>>
>> I think this would be a great change. We are part way there with
>> @noescape and @autoclosure already
>>
>> It would be interesting though to do a code survey and see what portion
>> would need to be marked as @impure, and what conditions lead them to that
>> requirement.
>>
>> I'm happy to discuss @impure too, but my focus is still @pure, as I think
>> it is a more attainable target, at the moment.
>>
>> Perhaps after everything is annotated, impure functions are minimised,
>> and if swift is streamlined for pure function use, then we can introduce
>> @impure and deprecate @pure.
>>
>>
>> Not sure either will happen any time soon :(. Therefore the most useful
>> thing would be the survey you suggest.
>>
>> On Sat, Jan 9, 2016 at 7:56 PM, Howard Lovatt <howard.lovatt at gmail.com>
>> wrote:
>>
>>> I would rather you mark a function as impure and have the default as
>>> pure!
>>>
>>>
>>>
>>>
>>> On 9 Jan 2016, at 7:53 PM, Andrew Bennett via swift-evolution <
>>> swift-evolution at swift.org> wrote:
>>>
>>> I'd like to discuss adding a @pure keyword, and see what it requires and
>>> how possible it is to  include.
>>>
>>> I'd like to use the annotation @pure on functions, methods and closures.
>>>
>>> This will allow us to make more guarantees about what a protocol does,
>>> and what it cannot do. It will also allow APIs like `.map` and `.forEach`
>>> to have a meaningful distinction. It could also allow for something like an
>>> assert to be removed as an optimisation with no side-effects in a release
>>> build.
>>>
>>> If something is pure it can be annotated with @pure, if it is not-pure
>>> this will be a compile-time error. The compiler could automatically add
>>> this annotation in the interface.
>>>
>>> A function, method or closure is pure if:
>>>  * all functions, methods and closures it calls are also pure (this
>>> includes referencing self from a method or property)
>>>  * it only externally references let variables of pure type, let
>>> properties on those variables, and methods/computer-properties marked as
>>> pure.
>>>
>>> A computed property can be marked as pure like this:
>>>
>>> @pure var test: A
>>>
>>>
>>> A function/method/closure signature is marked as pure like this:
>>>
>>> (a: A, b: A -> B) @pure -> B
>>>
>>>
>>> If the function/method/closure is only pure if an argument is pure
>>> (similar to @rethrows), then you could do this:
>>>
>>> (start: A, a: A -> B) @pure(b) -> B
>>>
>>>
>>> Potentially this could be extended to allow a pure closure to be
>>> composed of other pure closures:
>>>
>>> func compose(a: A -> B, b: B -> C) @pure -> A @pure(a,b) -> C {
>>>
>>>     return { b(a($0)) }
>>>
>>> }
>>>
>>>
>>> Of course this doesn't preclude you from requiring some of those
>>> closures to be pure:
>>>
>>> func compose(a: A @pure -> B, b: B -> C) @pure -> A @pure(b) -> C {
>>>
>>>     return { b(a($0)) }
>>>
>>> }
>>>
>>>
>>> Impact on existing code:
>>>
>>> No negative impact as if automatic annotation was allowed it would only
>>> happen where it was safe to do so. If it was not allowed then libraries
>>> could be slowly annotated to be marked as pure.
>>>
>>> c and objective-c would not be marked as pure.
>>>
>>> Pure functions can be safely removed by the optimiser if their result is
>>> not used. From this perspective assert and print should not be marked as
>>> pure (they would have to be an exception anyway).
>>>
>>> Ideally existing libraries would be annotated, the more the better, but
>>> this can be a gradual process.
>>>
>>>
>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>>
>>>
>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>
>
> --
> Best Regards!
>
> Yang Wu
> --------------------------------------------------------
> Location: Pudong, Shanghai, China.
> EMail    : pinxue at gmail.com
> Website: http://www.time2change.mobi http://rockplayer.com
> Twitter/Weibo : @pinxue
> <http://www.pinxue.net>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160110/422c5bb2/attachment-0001.html>