<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div></div><div>So here are some thoughts. I like the idea of an annotation for compile-time validation, though I haven't given up on simple #url yet either. For the people interested in @pure for its implications for functional programming, I'm questioning if that concept sufficiently limits the problem when you're talking about compilation. I'm a little worried about things like cyclical references--not knowing if one class compiles until you've run code from another class, or even another library. Is it clear that the concept of @pure is sufficient for this?</div><div><br></div><div>I FEEL like this is opening the door too far, at least a little.</div><div><br></div><div>If we did do something like this as more than a one-off for URL however the external API looks we still would need to talk about the internal mechanics of how something can be marked as a compile error. Is it something like a special throw happening inside the code? Is there a precompiler-type directive denoting code that executes inside the block happens only at compile time?</div><div><br></div><div>I'd love a fleshed out elegant example for URL that shows what a complete implementation of that special init method would look like. </div><div><br>On Dec 17, 2016, at 1:15 PM, Anton Zhilin via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr"><div class="markdown-here-wrapper" style=""><p style="margin:0px 0px 1.2em!important">I was in the process of writing something along those lines :)</p>
<p style="margin:0px 0px 1.2em!important">But I would prefer this attribute to be added implicitly by the compiler.<br>Then, if we want to <em>validate</em> that some function is statically computable, we add <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> to the function.<br>If we want to <em>require</em> that some variable is computed at compilation time (even if it takes a lot of time, even in debug builds), we add <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> to the declaration.</p>
<p style="margin:0px 0px 1.2em!important">2016-12-17 21:59 GMT+03:00 David Sweeris via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>>:</p>
<p style="margin:0px 0px 1.2em!important"></p><div class="markdown-here-exclude"><p></p><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">It wouldn't have to be restricted to a subset of the language; just to functions whose evaluation doesn't depend on anything that happens at runtime.<br>
<br>
Any "@pure" (or whatever... it's easier to type on my phone than "@constantExpression") function should work fine, if we define a "pure" function to be something like:<br>
1) Doesn't mutate anything outside its own scope<br>
2) Doesn't call anything involving rand() or other non-deterministic functions<br>
3) Doesn't have a result that depends on the host or target architectures (I'm not sure if this extends to FP subtleties)<br>
4) Doesn't reference any non-local variables which don't themselves have a value that's either itself a literal or the result of evaluating a "pure" function<br>
5) Doesn't call any other functions which aren't themselves "pure", or instantiate any variables using inits that aren't "pure"<br>
<br>
Since there's already a Swift REPL, at least conceptually speaking, this doesn't seem too hard (although it does raise the bar a bit for what it takes to have a "full" Swift compiler, since it'd then depend on having a working REPL on the host platform, which IIRC wasn't the case on Linux for a while... dunno, maybe this is a non-issue).</blockquote><p></p></div><p style="margin:0px 0px 1.2em!important"></p>
<div title="MDH:PGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj5JIHdhcyBp
biB0aGUgcHJvY2VzcyBvZiB3cml0aW5nIHNvbWV0aGluZyBhbG9uZyB0aGF0IGxpbmVzIDopPC9k
aXY+PGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPjxicj48L2Rpdj48ZGl2IGNsYXNzPSJnbWFpbF9x
dW90ZSI+QnV0IEkgd291bGQgcHJlZmVyIHRoaXMgYXR0cmlidXRlIHRvIGJlIGFkZGVkIGltcGxp
Y2l0bHkgYnkgdGhlIGNvbXBpbGVyLjwvZGl2PjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj5UaGVu
LCBpZiB3ZSB3YW50IHRvICp2YWxpZGF0ZSogdGhhdCBzb21lIGZ1bmN0aW9uIGlzIHN0YXRpY2Fs
bHkgY29tcHV0YWJsZSwgd2UgYWRkIGBAcHVyZWAgdG8gdGhlIGZ1bmN0aW9uLjwvZGl2PjxkaXYg
Y2xhc3M9ImdtYWlsX3F1b3RlIj5JZiB3ZSB3YW50IHRvICpyZXF1aXJlKiB0aGF0IHNvbWUgdmFy
aWFibGUgaXMgY29tcHV0ZWQgYXQgY29tcGlsYXRpb24gdGltZSAoZXZlbiBpZiBpdCB0YWtlcyBh
IGxvdCBvZiB0aW1lLCBldmVuIGluIGRlYnVnIGJ1aWxkcyksIHdlIGFkZCBgQHB1cmVgIHRvIHRo
ZSBkZWNsYXJhdGlvbi48L2Rpdj48ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+PGJyPjwvZGl2Pjxk
aXYgY2xhc3M9ImdtYWlsX3F1b3RlIj4yMDE2LTEyLTE3IDIxOjU5IEdNVCswMzowMCBEYXZpZCBT
d2VlcmlzIHZpYSBzd2lmdC1ldm9sdXRpb24gPHNwYW4gZGlyPSJsdHIiPiZsdDs8YSBocmVmPSJt
YWlsdG86c3dpZnQtZXZvbHV0aW9uQHN3aWZ0Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnN3aWZ0LWV2
b2x1dGlvbkBzd2lmdC5vcmc8L2E+Jmd0Ozwvc3Bhbj46PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWls
X3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29s
aWQ7cGFkZGluZy1sZWZ0OjFleCI+SXQgd291bGRuJ3QgaGF2ZSB0byBiZSByZXN0cmljdGVkIHRv
IGEgc3Vic2V0IG9mIHRoZSBsYW5ndWFnZTsganVzdCB0byBmdW5jdGlvbnMgd2hvc2UgZXZhbHVh
dGlvbiBkb2Vzbid0IGRlcGVuZCBvbiBhbnl0aGluZyB0aGF0IGhhcHBlbnMgYXQgcnVudGltZS48
YnI+Cjxicj4KQW55ICJAcHVyZSIgKG9yIHdoYXRldmVyLi4uIGl0J3MgZWFzaWVyIHRvIHR5cGUg
b24gbXkgcGhvbmUgdGhhbiAiQGNvbnN0YW50RXhwcmVzc2lvbiIpIGZ1bmN0aW9uIHNob3VsZCB3
b3JrIGZpbmUsIGlmIHdlIGRlZmluZSBhICJwdXJlIiBmdW5jdGlvbiB0byBiZSBzb21ldGhpbmcg
bGlrZTo8YnI+CjEpIERvZXNuJ3QgbXV0YXRlIGFueXRoaW5nIG91dHNpZGUgaXRzIG93biBzY29w
ZTxicj4KMikgRG9lc24ndCBjYWxsIGFueXRoaW5nIGludm9sdmluZyByYW5kKCkgb3Igb3RoZXIg
bm9uLWRldGVybWluaXN0aWMgZnVuY3Rpb25zPGJyPgozKSBEb2Vzbid0IGhhdmUgYSByZXN1bHQg
dGhhdCBkZXBlbmRzIG9uIHRoZSBob3N0IG9yIHRhcmdldCBhcmNoaXRlY3R1cmVzIChJJ20gbm90
IHN1cmUgaWYgdGhpcyBleHRlbmRzIHRvIEZQIHN1YnRsZXRpZXMpPGJyPgo0KSBEb2Vzbid0IHJl
ZmVyZW5jZSBhbnkgbm9uLWxvY2FsIHZhcmlhYmxlcyB3aGljaCBkb24ndCB0aGVtc2VsdmVzIGhh
dmUgYSB2YWx1ZSB0aGF0J3MgZWl0aGVyIGl0c2VsZiBhIGxpdGVyYWwgb3IgdGhlIHJlc3VsdCBv
ZiBldmFsdWF0aW5nIGEgInB1cmUiIGZ1bmN0aW9uPGJyPgo1KSBEb2Vzbid0IGNhbGwgYW55IG90
aGVyIGZ1bmN0aW9ucyB3aGljaCBhcmVuJ3QgdGhlbXNlbHZlcyAicHVyZSIsIG9yIGluc3RhbnRp
YXRlIGFueSB2YXJpYWJsZXMgdXNpbmcgaW5pdHMgdGhhdCBhcmVuJ3QgInB1cmUiPGJyPgo8YnI+
ClNpbmNlIHRoZXJlJ3MgYWxyZWFkeSBhIFN3aWZ0IFJFUEwsIGF0IGxlYXN0IGNvbmNlcHR1YWxs
eSBzcGVha2luZywgdGhpcyBkb2Vzbid0IHNlZW0gdG9vIGhhcmQgKGFsdGhvdWdoIGl0IGRvZXMg
cmFpc2UgdGhlIGJhciBhIGJpdCBmb3Igd2hhdCBpdCB0YWtlcyB0byBoYXZlIGEgImZ1bGwiIFN3
aWZ0IGNvbXBpbGVyLCBzaW5jZSBpdCdkIHRoZW4gZGVwZW5kIG9uIGhhdmluZyBhIHdvcmtpbmcg
UkVQTCBvbiB0aGUgaG9zdCBwbGF0Zm9ybSwgd2hpY2ggSUlSQyB3YXNuJ3QgdGhlIGNhc2Ugb24g
TGludXggZm9yIGEgd2hpbGUuLi4gZHVubm8sIG1heWJlIHRoaXMgaXMgYSBub24taXNzdWUpLjwv
YmxvY2txdW90ZT48L2Rpdj48YnI+PC9kaXY+" style="height:0;width:0;max-height:0;max-width:0;overflow:hidden;font-size:0em;padding:0;margin:0"></div></div></div>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></body></html>