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
Marking a URL like this @urlvalidation("a URL string") 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 On Sat, Dec 17, 2016 at 1:02 PM Callionica (Swift) via swift-evolution < swift-evolution@swift.org> wrote: > 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@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@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution > > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution