<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'm sure everyone agrees that it's annoying/risky when you can't even distinguish localizable strings (user messages) from non-localizable strings. I'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'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) "Web URLs" (specifically HTTP & 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"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></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 "knows what to do with itself".<br>
<span class=""><br>
let url: URL = "<a href="https://example.com" rel="noreferrer" target="_blank">https://example.com</a>"<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>