[swift-evolution] URL Literals

[Xiaodi Wu]

On Fri, Dec 16, 2016 at 7:01 PM, Micah Hainline <micah.hainline at gmail.com>
wrote:

> It's not super strong, but it's as strong as the URL type itself.
>
> Even if I do checking related to the resource being unavailable, I also
> have to do checking to account for the possibility of a nil URL. The two
> checks aren't closely related.
>

When you use a URL, what would you do differently when a resource is
unavailable versus when the URL is malformed, especially if you're
hardcoding the URL?

It does help to have one of them accounted for by the compiler if possible.
>
> I'm trying to teach some less experienced developers to think of
> force-unwrapping as a code smell,
>

There have been a few people who have said a similar thing on the list, but
I don't think this is the official line about force-unwrapping. Force
unwrapping is an explicitly supported part of the language that has its
uses. If you *know* at the time of writing that a failable initializer
should never fail, then `!` is an expressive, clear, concise, entirely
appropriate, and I would even say the *best* way of indicating that to your
reader.

It should be noted that `let url = URL(string: "http://example.com/")!` is
one example of this usage, but not at all the only one. I have previously
written, for example, `"L".cString(using: .utf8)!`. This is also no code
smell, as what I'm doing is stating my absolute confidence (and indicating
that confidence to the reader) that the letter L can be encoded using UTF-8.

but it's not the best to have to say "except for URLs". I realize the
> utility of the proposed change is reasonably small, but I also think it's
> purely additive and consistent with the rest of the language. 🙂
>
> On Dec 16, 2016, at 6:45 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>
> 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/c9c30eeb/attachment.html>