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.
On Sat, Dec 17, 2016 at 9:23 AM, Stephen Buck via swift-evolution < firstname.lastname@example.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