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
