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@swift.org) schrieb: 2017-02-17 17:13 GMT+03:00 T.J. Usiyan <griotsp...@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@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
