[swift-evolution] URL Literals

Callionica (Swift) swift-callionica at callionica.com
Sat Dec 17 12:02:07 CST 2016

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.

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:
1) A specific subtype for URLs in a protocol family:
    a) Local File URLs
    b) "Web URLs" (specifically HTTP & HTTPS)
2) A specific subtype for absolute URLs

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.

-- Callionica

On Sat, Dec 17, 2016 at 9:23 AM, Stephen Buck via swift-evolution <
swift-evolution at swift.org> wrote:

> I like the David Sweeris idea best. The syntax is cleaner and the type URL
> "knows what to do with itself".
> let url: URL = "https://example.com"
> 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.
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161217/c0feb03e/attachment.html>

More information about the swift-evolution mailing list