> On Jun 29, 2015, at 15:43 , Greg Parker <gpar...@apple.com> wrote:
>
>> On Jun 29, 2015, at 3:18 PM, Rick Mann <rm...@latencyzero.com> wrote:
>>
>> How are you supposed to do simple things like this, succinctly?
>>
>> let url = NSURL(string: "<some url>")
>> let req = NSURLRequest(URL: url)
>> self.webView.loadRequest(req)
>>
>> This, obviously, doesn't work, since the results are optionals, and so need
>> to be unwrapped. But it gets rapidly ridiculous with a bunch of nested
>> if-lets (imagine you had more than just two operations to get from here to
>> there). What's the right way to do this?
>
> If you "know" that the call cannot actually fail (for example, NSURL(string:)
> with a valid hardcoded URL) then you can simply force-unwrap. If you are
> wrong then the program will halt at runtime.
> let url = NSURL(string: "<some url>")!
Yep, part of the problem was I was expecting the two type to have the same
construction semantics, which isn't the case.
> If you are using Swift 2.0, you can use the new `guard let` to get optional
> checking without the cascade of indentation.
> guard let url = NSURL(string: "<some url>")
> else { /* handle failure and either halt or return */ }
> // URL is now in scope and non-optional.
> let req = NSURLRequest(URL: url)
I am, but this may not work as well if there are additional steps after this
one that should run anyway. Can I enclose the bit in braces to limit the scope
of the break? Probably not, huh? e.g.:
{
guard let url = ... else { break }
<use url>
}
{
...other init...
}
Quincey Morris pointed out that I can add multiple let clauses with commas. I
tried using &&, and even a where clause, but was being tripped up by NSURL
being optional and NSURLRequest not. Here's a contrived example, though. Would
this be gross?
let url = NSURL(string: "http://my.matterport.com/show?m=YJrquK9RCiE";)
if let url2 = NSURL(string: url!.absoluteString) where url != nil
{
...
}
>> Oh, I think I figured it out. NSURL(string:) is optional, but
>> NSURLRequest(URL:) can't. Very unexpected, and the error message I was
>> getting did not clue me in.
>
> You can often improve diagnostics by adding the explicit types that you
> expect each variable to have. That can help pinpoint the place where your
> understanding of the code and the compiler's understanding of the code don't
> match.
>
> For example, in your code above, writing `let url: NSURL = …` moves the error
> message from the NSURLRequest line to the NSURL line.
That sure seems to defeat the purpose of a highly publicized feature of the
language. Or are you suggesting just doing it temporarily to figure out what
the compiler really wants?
The compiler's message was, "Could not find an overload for 'init' that accepts
the supplied arguments." Could it instead say "NSURLRequst.init(URL:) does not
return Optional type"?
The confusion stems from it talking about what the init *accepts*, rather than
what it returns.
--
Rick Mann
rm...@latencyzero.com
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
