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

Anton Zhilin antonyzhilin at gmail.com
Fri Feb 17 10:15:17 CST 2017

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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170217/79047e92/attachment.html>

More information about the swift-evolution mailing list