[swift-evolution] Proposal proposal: @pure keyword

[品雪]

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/20160109/1e525c42/attachment.html>