[swift-evolution] URL Literals

[Xiaodi Wu]

On Fri, Dec 16, 2016 at 5:54 PM, Micah Hainline via swift-evolution <
swift-evolution at swift.org> wrote:

> True, but it's not at all about brevity, it's about type-safety and
> getting compile-time checking rather than runtime checking of the validity
> of the URL structure.
>

While I understand that what you're after is compile-time checking of
validity, I'm not convinced that it is materially useful. I also don't see
how it's contributing to type safety. Perhaps you could illuminate what use
case has persuaded you of these things? Here's my thinking:

Nine times out of ten when I mistype a URL, or paste only a fragment of a
URL, it's a mistake that results in a plausible but unintended URL and a
compile-time check for validity will not help at all. To guard against such
an error, I need to write tests anyway and could never depend on the
compiler. In fact, I'd imagine that doing anything useful with a URL--even
a hardcoded one--will require some thought as to how to deal with error
handling at runtime. How is it helpful to have only the lowest bar (a
technically valid URL format) ensured at compile time instead of runtime?
By contrast, Swift selectors help to guarantee that any particular function
I'm referring to actually exists; when that is ensured at compile time, I
know it will be the case at runtime. There's no corresponding guarantee by
having a compile-time check for URL validity that the resource pointed to
will actually exist. That the nonexistent resource was denoted by a string
that had the correct format of a URL is cold comfort, no?


On Dec 16, 2016, at 5:50 PM, Derrick Ho <wh1pch81n at gmail.com> wrote:
>
> let url = URL(string: "https://example.com")!
>
> let url = #url("https://example.com")
>
> Are not that different in length. It really isn't saving you much.
>
> I suppose you can try overloading an operator to get something to the
> effect you want.
> On Fri, Dec 16, 2016 at 6:19 PM Micah Hainline via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>> Exactly! It's not an earth-shattering pain, but it would be nice to have
>> clean type safety there.
>>
>> > On Dec 16, 2016, at 4:01 PM, Charlie Monroe <charlie at charliemonroe.net>
>> wrote:
>> >
>> >
>> >>> On Dec 16, 2016, at 10:05 PM, Charles Srstka via swift-evolution <
>> swift-evolution at swift.org> wrote:
>> >>>
>> >>> On Dec 16, 2016, at 2:46 PM, Micah Hainline via swift-evolution <
>> swift-evolution at swift.org> wrote:
>> >>>
>> >>> I would like to be able to create a URL literal that is compile-time
>> >>> checked for correct format. This would help avoid code like this:
>> >>>
>> >>>  let url: URL = URL(string: "https://example.com")!
>> >>>
>> >>> The cleanest way I can think of doing that would be to introduce a new
>> >>> macro structure similar to #selector, though I'm open to other ideas.
>> >>> I would think it should take a quoted literal string to avoid
>> >>> problems. That would look like this:
>> >>>
>> >>>  let url: URL = #url("https://example.com")
>> >>>
>> >>> What does everyone think of that idea?
>> >>> _______________________________________________
>> >>> swift-evolution mailing list
>> >>> swift-evolution at swift.org
>> >>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> >>
>> >>
>> >> I’d like to see something like that for file path URLs. For something
>> so commonly used, URL(fileURLWithPath:) is obnoxiously verbose.
>> >>
>> >> Charles
>> >
>> > Yes, but it's not a nullable initializer. With URL(string:) the
>> incredible pain is that even compile-time URLs to your own website are
>> nullable URL? and you need to force-unwrap them.
>> >
>> >>
>> >> _______________________________________________
>> >> swift-evolution mailing list
>> >> swift-evolution at swift.org
>> >> https://lists.swift.org/mailman/listinfo/swift-evolution
>> >
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>
> _______________________________________________
> 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/20161216/772f0e23/attachment.html>