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

[Adrian Zubarev]

I haven’t yet read all the feedback in this topic but I’d like to throw some bikeshedding of mine into the room. :)

How about this?

Version 1: func(pure) …
Version 2: func label(…) ~> ReturnType


-- 
Adrian Zubarev
Sent with Airmail

Am 17. Februar 2017 um 17:16:49, Anton Zhilin via swift-evolution (swift-evolution at swift.org) schrieb:

2017-02-17 17:13 GMT+03:00 T.J. Usiyan <griotspeak at gmail.com>:

It is my opinion that you are describing an entirely different, and somewhat orthogonal, feature. I would like the feature that you describe. Constant expressions are powerful and open up quite a few optimizations. What constexpr addresses is not purity, at the heart of it. Pure expressions that accept compile-time-known values are, by happy accident, compile-time-computable, but pure expressions that accept dynamic values are not. Conflating the two qualities of being compile-time-known and being pure within the same keyword and overloading it in this way is not desirable to me.
I see now. I’d say that access to global state is not vital, and  
@pure functions are more useful than  
@const functions, so I’m OK with having only  
@const functions.

To control growth of compilation time, we could have both  
@pure function annotation and  
@const variable annotation to ensure that a  
@pure expression is computed at compilation time.

I’d also want to infer  
@pure whenever possible, but is it possible with functions in different modules?

_______________________________________________
swift-evolution mailing list
swift-evolution at swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170217/960037ec/attachment.html>