[swift-evolution] URL Literals

Xiaodi Wu xiaodi.wu at gmail.com
Mon Dec 19 12:39:04 CST 2016 

On Mon, Dec 19, 2016 at 8:47 AM, Micah Hainline via swift-evolution <
swift-evolution at swift.org> wrote:

> Regarding validation of resources being reachable or existing, I think we
> should take that right off the table, for all types of URLs. Firstly,
> because it could be very error prone. Consider even the basic case of the
> deployment environment having access to the resource while the build
> environment does not. Consider the resource being available at run time but
> not compile time. That applies to file urls and every other kind.
>

File literals already do this, don't they?


> Secondly, it would be dangerous on many levels.
>
> On Mon, Dec 19, 2016 at 3:39 AM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>
>> 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
>>>
>>>
>>
>
> _______________________________________________
> 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/f908d474/attachment.html>

More information about the swift-evolution mailing list