Re: Instantiate NSString from NSURL in Swift
Re: Instantiate NSString from NSURL in Swift
- Subject: Re: Instantiate NSString from NSURL in Swift
- From: Charles Srstka <email@hidden>
- Date: Mon, 23 Feb 2015 20:53:35 -0600
On Feb 23, 2015, at 1:52 PM, Fritz Anderson <email@hidden> wrote:
>
> This is written in haste, and few people are experts…
>
> theURL.host may yield nil (host is declared String!, implicitly unwrapped, but optional).
>
> theURL.host?.lowercaseString will short-circuit and be evaluated as nil if .host is nil.
>
> anyString.lowercaseString may also yield nil; the var is declared String!.
>
> anyString.lowercaseString! attempts to unwrap a String that the compiler has implicitly unwrapped already.
>
> Therefore, because of the short-circuit “?”, the expression theUrl.host?.lowercaseString is of type String?, which may be .None (nil), or .Some(String) (and therefore have to be unwrapped).
>
> You are passing that optional String as the argument for String(string: {that optional expression}). The argument may be nil; or it may need unwrapping. The initializer _requires_ a non-nil argument. It’s a righteous error.
>
> The expression
>
> NSString(string: foo!)
>
> is different; by adding the bang you’ve taken responsibility for the parameter’s not being nil.
>
> Because .lowercaseString returns an implicitly-unwrapped String (String!),
>
> theURL?.host?.lowercaseString!
>
> tries to unwrap something that is already, syntactically, an unwrapped String.
>
> Quincey — my instinct is that the conditional-unwrap chain necessarily forces left-to-right evaluation, tighter than the . operator. The ! would mean, “if you got this far without short-circuiting, and b returns an optional, then unwrap it.”
>
> As of today’s Swift 1.2b2, the following in a playground:
>
> let aURL = NSURL(string: "http://wt9t.com/ <http://wt9t.com/>")!
> NSString(string: aURL.host?.lowercaseString)
>
> complains as you suggest: .host? is potentially nil — that would force the whole expression to be nil, and thus forbidden as a parameter. lowercaseString still gets treated as implicitly unwrapped — so a bang at the end of the whole expression is an attempt to unwrap something the compiler was going to unwrap anyway.
It’s sure great that we have Swift these days to make our coding so much easier, isn’t it?
Charles
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden