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

[T.J. Usiyan]

Anton,

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.


Thank you,
TJ

On Fri, Feb 17, 2017 at 8:01 AM, Anton Zhilin via swift-evolution <
swift-evolution at swift.org> wrote:

> My vision of “pure” functions was the following:
>
>    1. Compiler automatically marks all functions and expressions as pure,
>    wherever possible
>       - We should be interested not in “Haskell-ish pure” functions, but
>       in “computable during compilation” functions
>       - Therefore I prefer to use @constexpr or const instead of @pure
>    2. We can mark a function as const to *assert* that it is indeed pure
>    3. We can mark a variable as const to *ensure* that it’s computed at
>    compilation time
>       - Compiler might compute some non-const expressions, but no
>       guarantees given
>
> One issue is, we don’t have or suggest any facilities to make use of pure
> functions, other than some optimization, which can be performed anyway as
> of now.
>
> One use-case would be conversion of metatypes to types:
>
> const let x: Any = makeSomething()
> typealias T = type(of: x)
>
> This feature can be powerful enough to fill the niche of macros in Swift,
> without unsafety of C++ or specific syntax of Rust.
>
> 2017-02-17 14:14 GMT+03:00 Haravikk via swift-evolution <
> swift-evolution at swift.org>:
>
> I like the idea of having pure functions in Swift, but my first thought
>> is; should we have to declare it at all? Is it not easier to just have the
>> compiler automatically flag a function as pure or not?
>>
>> With that in mind we don't need any new syntax, but a simple @pure
>> attribute should be sufficient. This can be used anywhere that a function
>> is declared, or a closure is accepted as a parameter, allowing us to be
>> explicit that we are trying to define a pure function, or only accept pure
>> closures.
>>
>> The big benefit of this is that it is retroactive; all existing functions
>> that are pure will be automatically detected as such, and can be passed
>> into any method accepting only pure functions. The new capability will be
>> that developers can specify that a function *must* be pure and thus produce
>> an error if it isn't.
>>
> ​
>
> _______________________________________________
> 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/2f504ecf/attachment.html>