On Feb 23, 2015, at 1:52 PM, Fritz Anderson <fri...@manoverboard.org> wrote: > > On 23 Feb 2015, at 8:18 AM, Juanjo Conti <jjco...@carouselapps.com > <mailto:jjco...@carouselapps.com>> wrote: >> >> I'm translating some code from Objective-C to Swift and in the middle of >> that, i found this problem. >> >> theUrl is an instance of NSURL >> >> theUrl.host?.lowercaseString >> >> compiles ok. >> >> But >> >> NSString(string: theUrl.host?.lowercaseString) >> don't. It says "Value of optional type 'String?' no unwrapped; did you mean >> to use '!' or '?'? >> >> If I click to add the fix, then it complains again and suggest to delete >> the '!' :) > > 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 (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