<div dir="ltr">Anton,<div><br></div><div>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.</div><div><br></div><div><br></div><div>Thank you,</div><div>TJ</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 17, 2017 at 8:01 AM, Anton Zhilin via swift-evolution <span dir="ltr">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="m_5263759464356799057markdown-here-wrapper"><p style="margin:0px 0px 1.2em!important">My vision of “pure” functions was the following:</p>
<ol style="margin:1.2em 0px;padding-left:2em">
<li style="margin:0.5em 0px">Compiler automatically marks all functions and expressions as pure, wherever possible<ul style="margin:1.2em 0px;padding-left:2em;margin:0px;padding-left:1em">
<li style="margin:0.5em 0px">We should be interested not in “Haskell-ish pure” functions, but in “computable during compilation” functions</li>
<li style="margin:0.5em 0px">Therefore I prefer to use <code style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;padding:0px 0.3em;white-space:pre-wrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-radius:3px;display:inline">@constexpr</code> or <code style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;padding:0px 0.3em;white-space:pre-wrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-radius:3px;display:inline">const</code> instead of <code style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;padding:0px 0.3em;white-space:pre-wrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-radius:3px;display:inline">@pure</code></li>
</ul>
</li>
<li style="margin:0.5em 0px">We can mark a function as <code style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;padding:0px 0.3em;white-space:pre-wrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-radius:3px;display:inline">const</code> to <em>assert</em> that it is indeed pure</li>
<li style="margin:0.5em 0px">We can mark a variable as <code style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;padding:0px 0.3em;white-space:pre-wrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-radius:3px;display:inline">const</code> to <em>ensure</em> that it’s computed at compilation time<ul style="margin:1.2em 0px;padding-left:2em;margin:0px;padding-left:1em">
<li style="margin:0.5em 0px">Compiler might compute some non-<code style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;padding:0px 0.3em;white-space:pre-wrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-radius:3px;display:inline">const</code> expressions, but no guarantees given</li>
</ul>
</li>
</ol>
<p style="margin:0px 0px 1.2em!important">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.</p>
<p style="margin:0px 0px 1.2em!important">One use-case would be conversion of metatypes to types:</p>
<pre style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;font-size:1em;line-height:1.2em;margin:1.2em 0px"><code style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;padding:0px 0.3em;white-space:pre-wrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-radius:3px;display:inline;white-space:pre-wrap;overflow:auto;border-radius:3px;border:1px solid rgb(204,204,204);padding:0.5em 0.7em;display:block!important">const let x: Any = makeSomething()
typealias T = type(of: x)
</code></pre><p style="margin:0px 0px 1.2em!important">This feature can be powerful enough to fill the niche of macros in Swift, without unsafety of C++ or specific syntax of Rust.</p><span class="">
<p style="margin:0px 0px 1.2em!important">2017-02-17 14:14 GMT+03:00 Haravikk via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;:</p>
<p style="margin:0px 0px 1.2em!important"></p><div class="m_5263759464356799057markdown-here-exclude"><p></p><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>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?</div><div><br></div><div>With that in mind we don&#39;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.</div><div><br></div><div>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&#39;t.</div></div></blockquote><p></p></div><p style="margin:0px 0px 1.2em!important"></p>
<div title="MDH:TXkgdmlzaW9uIG9mICJwdXJlIiBmdW5jdGlvbnMgd2FzIHRoZSBmb2xsb3dpbmc6PGRpdj48YnI+
PC9kaXY+PGRpdj4xLiBDb21waWxlciBhdXRvbWF0aWNhbGx5IG1hcmtzIGFsbCBmdW5jdGlvbnMg
YW5kIGV4cHJlc3Npb25zIGFzIHB1cmUsIHdoZXJldmVyIHBvc3NpYmxlPC9kaXY+PGRpdj4mbmJz
cDsgKiBXZSBzaG91bGQgYmUgaW50ZXJlc3RlZCBub3QgaW4gIkhhc2tlbGwtaXNoIHB1cmUiIGZ1
bmN0aW9ucywgYnV0IGluICJjb21wdXRhYmxlIGR1cmluZyBjb21waWxhdGlvbiIgZnVuY3Rpb25z
PC9kaXY+PGRpdj4mbmJzcDsgKiBUaGVyZWZvcmUgSSBwcmVmZXIgdG8gdXNlIGBAY29uc3RleHBy
YCBvciBgY29uc3RgIGluc3RlYWQgb2YgYEBwdXJlYDwvZGl2PjxkaXY+Mi4gV2UgY2FuIG1hcmsg
YSBmdW5jdGlvbiBhcyBgY29uc3RgIHRvICphc3NlcnQqIHRoYXQgaXQgaXMgaW5kZWVkIHB1cmU8
L2Rpdj48ZGl2PjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj4zLiBXZSBjYW4gbWFyayBhIHZhcmlh
YmxlIGFzIGBjb25zdGAgdG8gKmVuc3VyZSogdGhhdCBpdCdzIGNvbXB1dGVkIGF0IGNvbXBpbGF0
aW9uIHRpbWU8L2Rpdj48ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+Jm5ic3A7ICogQ29tcGlsZXIg
bWlnaHQgY29tcHV0ZSBzb21lIG5vbi1gY29uc3RgIGV4cHJlc3Npb25zLCBidXQgbm8gZ3VhcmFu
dGVlcyBnaXZlbjwvZGl2PjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj48YnI+PC9kaXY+PGRpdiBj
bGFzcz0iZ21haWxfZXh0cmEiPk9uZSBpc3N1ZSBpcywgd2UgZG9uJ3QgaGF2ZSBvciBzdWdnZXN0
IGFueSBmYWNpbGl0aWVzIHRvIG1ha2UgdXNlIG9mIHB1cmUgZnVuY3Rpb25zLCBvdGhlciB0aGFu
IHNvbWUgb3B0aW1pemF0aW9uLCB3aGljaCBjYW4gYmUgcGVyZm9ybWVkIGFueXdheSBhcyBvZiBu
b3cuPC9kaXY+PGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPjxicj48L2Rpdj48ZGl2IGNsYXNzPSJn
bWFpbF9leHRyYSI+T25lIHVzZS1jYXNlIHdvdWxkIGJlIGNvbnZlcnNpb24gb2YgbWV0YXR5cGVz
IHRvIHR5cGVzOjxicj48L2Rpdj48ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+PGJyPjwvZGl2Pjxk
aXYgY2xhc3M9ImdtYWlsX2V4dHJhIj5gYGA8L2Rpdj48ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+
Y29uc3QgbGV0IHg6IEFueSA9IG1ha2VTb21ldGhpbmcoKTwvZGl2PjxkaXYgY2xhc3M9ImdtYWls
X2V4dHJhIj50eXBlYWxpYXMgVCA9IHR5cGUob2Y6IHgpPC9kaXY+PGRpdiBjbGFzcz0iZ21haWxf
ZXh0cmEiPmBgYDwvZGl2PjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj48YnI+PC9kaXY+PGRpdiBj
bGFzcz0iZ21haWxfZXh0cmEiPlRoaXMgZmVhdHVyZSBjYW4gYmUgcG93ZXJmdWwgZW5vdWdoIHRv
IGZpbGwgdGhlIG5pY2hlIG9mIG1hY3JvcyBpbiBTd2lmdCwgd2l0aG91dCB1bnNhZmV0eSBvZiBD
Kysgb3Igc3BlY2lmaWMgc3ludGF4IG9mIFJ1c3QuPC9kaXY+PGRpdiBjbGFzcz0iZ21haWxfZXh0
cmEiPjxicj48ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+MjAxNy0wMi0xNyAxNDoxNCBHTVQrMDM6
MDAgSGFyYXZpa2sgdmlhIHN3aWZ0LWV2b2x1dGlvbiA8c3BhbiBkaXI9Imx0ciI+Jmx0OzxhIGhy
ZWY9Im1haWx0bzpzd2lmdC1ldm9sdXRpb25Ac3dpZnQub3JnIiB0YXJnZXQ9Il9ibGFuayI+c3dp
ZnQtZXZvbHV0aW9uQHN3aWZ0Lm9yZzwvYT4mZ3Q7PC9zcGFuPjo8YnI+PGJsb2NrcXVvdGUgY2xh
c3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4
ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+PGRpdiBzdHlsZT0id29yZC13cmFwOmJyZWFr
LXdvcmQiPjxkaXY+SSBsaWtlIHRoZSBpZGVhIG9mIGhhdmluZyBwdXJlIGZ1bmN0aW9ucyBpbiBT
d2lmdCwgYnV0IG15IGZpcnN0IHRob3VnaHQgaXM7IHNob3VsZCB3ZSBoYXZlIHRvIGRlY2xhcmUg
aXQgYXQgYWxsPyBJcyBpdCBub3QgZWFzaWVyIHRvIGp1c3QgaGF2ZSB0aGUgY29tcGlsZXIgYXV0
b21hdGljYWxseSBmbGFnIGEgZnVuY3Rpb24gYXMgcHVyZSBvciBub3Q/PC9kaXY+PGRpdj48YnI+
PC9kaXY+PGRpdj5XaXRoIHRoYXQgaW4gbWluZCB3ZSBkb24ndCBuZWVkIGFueSBuZXcgc3ludGF4
LCBidXQgYSBzaW1wbGUgQHB1cmUgYXR0cmlidXRlIHNob3VsZCBiZSBzdWZmaWNpZW50LiBUaGlz
IGNhbiBiZSB1c2VkIGFueXdoZXJlIHRoYXQgYSBmdW5jdGlvbiBpcyBkZWNsYXJlZCwgb3IgYSBj
bG9zdXJlIGlzIGFjY2VwdGVkIGFzIGEgcGFyYW1ldGVyLCBhbGxvd2luZyB1cyB0byBiZSBleHBs
aWNpdCB0aGF0IHdlIGFyZSB0cnlpbmcgdG8gZGVmaW5lIGEgcHVyZSBmdW5jdGlvbiwgb3Igb25s
eSBhY2NlcHQgcHVyZSBjbG9zdXJlcy48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PlRoZSBiaWcg
YmVuZWZpdCBvZiB0aGlzIGlzIHRoYXQgaXQgaXMgcmV0cm9hY3RpdmU7IGFsbCBleGlzdGluZyBm
dW5jdGlvbnMgdGhhdCBhcmUgcHVyZSB3aWxsIGJlIGF1dG9tYXRpY2FsbHkgZGV0ZWN0ZWQgYXMg
c3VjaCwgYW5kIGNhbiBiZSBwYXNzZWQgaW50byBhbnkgbWV0aG9kIGFjY2VwdGluZyBvbmx5IHB1
cmUgZnVuY3Rpb25zLiBUaGUgbmV3IGNhcGFiaWxpdHkgd2lsbCBiZSB0aGF0IGRldmVsb3BlcnMg
Y2FuIHNwZWNpZnkgdGhhdCBhIGZ1bmN0aW9uICptdXN0KiBiZSBwdXJlIGFuZCB0aHVzIHByb2R1
Y2UgYW4gZXJyb3IgaWYgaXQgaXNuJ3QuPC9kaXY+PC9kaXY+PC9ibG9ja3F1b3RlPjwvZGl2Pjwv
ZGl2PjwvZGl2Pg==" style="height:0;width:0;max-height:0;max-width:0;overflow:hidden;font-size:0em;padding:0;margin:0">​</div></span></div></div>
<br>______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
<br></blockquote></div><br></div>