<div dir="ltr">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><br></div><div>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>1) A specific subtype for URLs in a protocol family:</div><div>    a) Local File URLs</div><div>    b) &quot;Web URLs&quot; (specifically HTTP &amp; HTTPS)</div><div>2) A specific subtype for absolute URLs</div><div><br></div><div>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><br></div><div>-- Callionica</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Dec 17, 2016 at 9:23 AM, Stephen Buck 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">I like the David Sweeris idea best. The syntax is cleaner and the type URL &quot;knows what to do with itself&quot;.<br>
<span class=""><br>
let url: URL = &quot;<a href="https://example.com" rel="noreferrer" target="_blank">https://example.com</a>&quot;<br>
<br>
</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>
<div class="HOEnZb"><div class="h5">______________________________<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>
</div></div></blockquote></div><br></div>