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. 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@swift.org> wrote:
>
>> On Fri, Dec 16, 2016 at 7:01 PM, Micah Hainline <micah.hainl...@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...@gmail.com> wrote:
>>>
>>>> On Fri, Dec 16, 2016 at 5:54 PM, Micah Hainline via swift-evolution
>>>> <swift-evolution@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 <wh1pch...@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@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
>>>>>> > <char...@charliemonroe.net> wrote:
>>>>>> >
>>>>>> >
>>>>>> >>> On Dec 16, 2016, at 10:05 PM, Charles Srstka via swift-evolution
>>>>>> >>> <swift-evolution@swift.org> wrote:
>>>>>> >>>
>>>>>> >>> On Dec 16, 2016, at 2:46 PM, Micah Hainline via swift-evolution
>>>>>> >>> <swift-evolution@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@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@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
>>>>
>>>
>
> _______________________________________________
> 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
