I suppose if compile time validation is desired I guess we can do something similar to @ibdesignables. Except instead of live rendering UIViews we would render the url<br><br>Marking a URL like this<br>@urlvalidation(&quot;a URL string&quot;)<br><br>Would make it fire a compiletime URL request and give a warning if it was a bad URL but if it is a good URL then it returns a URL instance <br><div class="gmail_quote"><div dir="ltr">On Sat, Dec 17, 2016 at 1:02 PM Callionica (Swift) via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg">It would be a good idea for literals of different types to be easily recognizable in the source by human readers and extractable from the source by tools. I&#39;m sure everyone agrees that it&#39;s annoying/risky when you can&#39;t even distinguish localizable strings (user messages) from non-localizable strings. I&#39;m in support of the (separate) concepts of 1) better compile time support for URLs and 2) better compile time support for user code (literal parsing; constexpr; macros). I hope the solution will consider how refactoring tools can extract literal URLs from the source and replace with URLs read from a configuration.<div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">I won&#39;t risk derailing the thread completely by going in to detail, but when I think of better compile-time support for URLs, the features that I first think of are:</div><div class="gmail_msg">1) A specific subtype for URLs in a protocol family:</div><div class="gmail_msg">    a) Local File URLs</div><div class="gmail_msg">    b) &quot;Web URLs&quot; (specifically HTTP &amp; HTTPS)</div><div class="gmail_msg">2) A specific subtype for absolute URLs</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Those are library-level concerns, but I mention them so that anyone with a general interest in improving compile time support for URLs might have a chance of finding them.</div></div><div dir="ltr" class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">-- Callionica</div><div class="gmail_msg"><br class="gmail_msg"></div></div><div class="gmail_extra gmail_msg"><br class="gmail_msg"><div class="gmail_quote gmail_msg">On Sat, Dec 17, 2016 at 9:23 AM, Stephen Buck via swift-evolution <span dir="ltr" class="gmail_msg">&lt;<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>&gt;</span> wrote:<br class="gmail_msg"><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I like the David Sweeris idea best. The syntax is cleaner and the type URL &quot;knows what to do with itself&quot;.<br class="gmail_msg">
<span class="gmail_msg"><br class="gmail_msg">
let url: URL = &quot;<a href="https://example.com" rel="noreferrer" class="gmail_msg" target="_blank">https://example.com</a>&quot;<br class="gmail_msg">
<br class="gmail_msg">
</span>I have strong reservations about hard-coded URLs as an SDLC 🚂 wreck waiting to happen, but the world of mid-day build and deploy might mitigate this, except when the developers are laid off and an acquisition or service consolidation causes a domain or URL change.  Having seen this many times I have always put URLs in a properties file for bootstrapping, and a database for post-bootstrap.  This allows per-instance customization and live instance changes which is also usually necessary.<br class="gmail_msg">
<div class="m_1711233524320590081HOEnZb gmail_msg"><div class="m_1711233524320590081h5 gmail_msg">_______________________________________________<br class="gmail_msg">
swift-evolution mailing list<br class="gmail_msg">
<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg">
</div></div></blockquote></div><br class="gmail_msg"></div>
_______________________________________________<br class="gmail_msg">
swift-evolution mailing list<br class="gmail_msg">
<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg">
</blockquote></div>