[swift-evolution] URL Literals

Xiaodi Wu xiaodi.wu at gmail.com
Mon Dec 19 03:39:42 CST 2016 

On Mon, Dec 19, 2016 at 1:55 AM, Benjamin Spratling <bspratling at mac.com>
wrote:

> Howdy,
>     I'm definitely on the "no force unwrapping bandwagon".  And I also see
> a huge difference in force-unwrapping a value derived from a literal, which
> can be unit tested, and force-unwrapping a value determined at run time,
> which might fail validation.  That's where I draw the line.
>
> I have seen some good developers "think" they "know" the value can't be
> nil, and they were just wrong.
>

Well, sure, but the fault originated with the good developer being wrong,
not with `!`. All I'm saying is, there are legitimate use cases where one
intends to have this behavior:

```
guard let foo = bar else {
  fatalError() // Bye.
}
```

In those cases, it is perfectly legitimate to write:

```
let foo = bar!
```

But when we can specifically run a unit test with 0 inputs on the value,
> then falsification of nullability is easy.
>
> -Ben
>
> Sent from my iPhone.
>
> On Dec 16, 2016, at 7:30 PM, Xiaodi Wu via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> 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
>>>
>>>
>>
> _______________________________________________
> 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/20161219/36189f0d/attachment.html>

More information about the swift-evolution mailing list