I'm a little confused about Swift Wrap and Unwrap! So lets say this is my code:
var name:String? = "FirstName"
print(name)
Does the print function automatically unwrap the name which is optional? so I do not need to say
print(name!) in order to unwrap the name?
I guess what I am trying to understand is these two are equivalent for unwraping an optional variable?
print("name") is just like saying print ("name"!)
The other question I have is about nil.
is saying var name:String? = "FirstName" equivalent to saying var name:String? = nil . So does assigning a nil value wraps a variable?
When something can be nil it can be two things, it can be Some (the value of the given type) or it can be nil.
declaring something like this:
var name: String?
Means that the name variable can be nil, if you assigned a value to it you need to unwrap it to use it.
name = "FirstName"
Now the name variable has been defined, however you still need to ensure it's not nil in some cases, in other cases however (such as when the string doesn't need to be not nil) optional chaining is used.
Optional chaining allows the continuous evaluation of nil or some throughout a statement as long as it's not required to be not nil. If that is the case then you will need to unwrap it:
let someThingRequiresAString = NeedAStringInitializer(string: name!)
In the above statement if name is nil the program will crash, there are several approaches to dealing with things like this, here's a quick example:
if name != nil {
let someThingRequiresAString = NeedAStringInitializers(string: name!)
}
Here you know you can do this b/c name has been evaluated to not be nil. You can also use a nil coalescing operator, or a guard statement. Here's a quick example of nil coalescence in Swift:
let someThingRequiresAString = NeedAStringInit(string: name ?? "New Name")
The optional paradigm is quite powerful and expressive.
Related
I am mocking a method call as follows:
tctx.someMock.On("addProd",
product.NewAddProductParamsWithContext(ctx).
WithID("someid").
WithCreateRequest(pro.CreateProdBody{
creationDate: "someDate" ,
}), nil).
Return(nil, nil)
which works fine.
Now, here, instead of passing a fixed value for the field creationDate, if I want to generalize it so it will work for any value passed, how can I achieve that? I am pretty new to Go, so not sure how to do this
the values for creationDate could be any value like - 2021-03-19T18:57:16.589Z or 2022-04-23T14:17:56.589Z etc. I just dont want to limit the mock call to work for a fixed value of creationDate, but I would like it to work for any date string passed
Assuming you're using github.com/stretchr/testify/mock, you should be able to use mock.MatchedBy() to match on specific parts of the argument. For example:
tctx.someMock.On("addProd", mock.MatchedBy(func(i interface{}) bool {
p := i.(*product.AddProductParams)
return p.ID() == "someid"
})).Return(nil, nil)
However, I find this to be most useful when needing to take a different action depending on the input. If you're simply verifying addProd was called with a specific argument, consider asserting that instead:
tctx.someMock.On("addProd", mock.Anything).Return(nil, nil)
...
tctx.someMock.AssertCalled(t, "addProd", mock.MatchedBy(func(i interface{}) bool {
p := i.(*product.AddProductParams)
return p.ID() == "someid"
})).Return(nil, nil)
When I was sifting through some of the class discussions for AVFoundation, I stumbled upon the following:
class func defaultDeviceWithMediaType(mediaType: String!) -> AVCaptureDevice!
Because optionals are a new concept to me, I'm a bit confused.
The discussion says that this method could either return "the default device with the given media type, or nil if no device with that media type exists." However, if there is a possibility that it's returning nil, why do they unwrap this optional in the return statement? Shouldn't it be AVCaptureDevice?
Then, when looking at an example that utilizes the above method, I find the following:
public lazy var device = AVCaptureDevice.defaultDeviceWithMediaType(AVMediaTypeVideo)
public func hasFlash() -> Bool {
if let d = self.device {
return d.hasFlash
}
return false
}
From what I understand, you would use an if let statement when you have an optional, but because the class defaultDeviceWithMediaType returns an unwrapped variable, why is having an if let necessary?
Thank you so much in advance.
Implicitly unwrapped optional is basically an optional, that gets an ! everywhere you use it. Thats it.
e.g.:
//this:
var number: Int? = ...
print(number!)
//is the same as this:
var number: Int! = ...
print(number)
An implicitly unwrapped optional is only to save you the need of unwrapping it every time you use it, wether with if let or with an !, but it has the same optionality of being nil as a normal optional.
A popular use of Implicitly unwrapped optionals is with outlets - they can't be non-optionals because we don't init them in the init of the VC, but we definitely have them later, so having them unwrapped saves us the need to do annoying things like if let table = self.tableView....
An implicitly unwrapped optional is still an optional - it could be nil. If you simply write self.device.hasFlash, when self.device is nil, you will get an exception.
I'm making the transition from learning Ruby to Swift and trying to make any useful associations in order to get a better understanding of similar concepts from both programming languages. I noticed in Swift there are optionals which either have or don't have a value assigned to variables.
var optinalString: String? = "This is optional"
In Ruby we have ||= which from what I understand does something very similar where if the user doesn't assign a value to this variable, then it will use the predefined one that's already been set.
optionalString ||= "This is optional"
Am I on the right track with this assumption? Overall what makes these concepts similar/different?
These two concepts are not equivalent.
In your Swift example, you're creating a variable of type String? and assigning it the value of a string literal. In the Ruby example, you're assigning a string literal to your optionalString variable if optionalString is undefined, nil, or evaluates false (more info).
In Swift, when you create a variable of optional type, all you're doing is specifying that the variable is allowed to be nil, so a closer representation of your Ruby example might look like this:
var optionalString: String?
optionalString = optionalString ?? "This is optional"
Which uses Swift's nil coalescing operator and is equivalent to the following usage of the ternary conditional operator, where optionalString is assigned the unwrapped value of optionalString if it isn't nil, or a fallback value of "This is optional" if it isn't.
optionalString = optionalString != nil ? optionalString! : "This is optional"
Note that by doing this, your variable will still have an optional type and need to be unwrapped to be used, and since you're fallback value is a string literal that won't ever be nil, you can confidently forcibly unwrap the optional with the ! operator.
But even though this can be used to set a variable with a fallback value, it still isn't entirely the same as your Ruby example since all it's doing is checking the nilness of the variable, and not whether it evaluates false or is undefined.
In Swift, you can't test the falseness of variables by sticking them into conditions unless they are instances of a type that conforms to the BooleanType protocol. This means that if you wanted to achieve something similar with a type that supports a falseness check, you could implement something like this:
var optionalBool: Bool? = false
optionalBool = optionalBool != nil ? (!optionalBool! ? true : optionalBool!) : true
Which will assign a fallback value of true to the optionalBool variable if the variable is either nil or evaluates to false. (optionalBool will still need to be unwrapped for most uses)
But this still leaves a difference with undefined variables, and as far as I know, there isn't any way to achieve the equivalence to Ruby's ||= in this regard in Swift without inlining the nilness checks in the instantiation of a variable based on a fallback value and the value of some other variable.
var optionalString: String?
var nonOptionalString = optionalString ?? "This is not optional"
Note, there's no point in nonOptionalString being optional here, since it will always have a value.
I understand that in Swift, if I define
var opt:String? = "Optional"
I will get an error if I attempt
opt.isEmpty
since opt is of type String? which does does not have an isEmpty method. And I thought that I understood that
opt?.isEmpty
does not produce an error because opt? unwraps (any non-nil) opt, resulting in a String, which does have an isEmpty method. But
opt?
on its own results in a String? and not a String.
Is ?. a different operator from ? followed by .?
Try
(opt?).isEmpty
and get a suggestive error.
Yes opt?.isEmpty is different from String?.It is called optional chaining.From swift programming guide:
You specify optional chaining by placing a question mark (?) after the
optional value on which you wish to call a property, method or
subscript if the optional is non-nil. This is very similar to placing
an exclamation mark (!) after an optional value to force the
unwrapping of its value. The main difference is that optional chaining
fails gracefully when the optional is nil, whereas forced unwrapping
triggers a runtime error when the optional is nil.
This creates optional as you thinking
var opt:String?
Now
opt?.isEmpty //it will not crash if opt is nil
is same as except
opt!.isEmpty //it will crash if opt is nil
if opt! is nil than it will not crash at runtime.Optional chaining is used to call long sequences of optional without calling.Every optional chain returns optional i.e opt? returns optional unwraps it and if nil than not call isEmpty else call isEmpty and reutns value.
Also
(opt?).isEmpty
When you are writing above statement it is just optional(not optional of optional) and it fails to unwrap because of braces.So error is showing
$T2?? does not have a member named `isEmpty`
to unwrap it use
(opt?)!.isEmpty
it will return false
Edit: To clarify more
var o1 = opt?
var o2 = ((opt?)?)
is doing nothing in its own it just assign same value to o1,o2 i.e String?.
to unwrap opt and o1,o2 they both are optional and need single ! operator to unwrap it.
Also please do not misunderstood between String? and opt? they both are different when ? is used after some type in decleration it makes optional and when ? used after variable optit is used for unwrap in optional chaining and return optional value it is returning
Extra Stuff:
try this to more clarify
(((opt?)?)!).isEmpty //it will unwrap with single !
((((opt?)?)!)?).isEmpty //compiler will show suggestion to remove ?
the below statement makes optional of optional of optional
var opt:String??? = "Optional"
to unwrap
opt!!!.isEmpty
EDIT2
opt? always return optional but if opt is defined as String! it is implicit optional and opt? will return optional(explicit).But if opt is already optional opt? will do nothing
From swift programming guide
To put it another way:
If the type you are trying to retrieve is not optional, it will become optional because of the optional chaining.
If the type you are trying to retrieve is already optional, it will not become more optional because of the chaining.
Therefore:
If you try to retrieve an Int value through optional chaining, an Int? is always returned, no matter how many levels of chaining are used.
Similarly, if you try to retrieve an Int? value through optional chaining, an Int? is always returned, no matter how many levels of chaining are used.
But opt? on its own results in a String? and not a String.
Yes. According to the Swift language reference, Expressions, Postfix Expressions, Optional-Chaining Expression:
On its own, the postfix ? operator simply returns the value of its
argument as an optional.
So putting a ? by itself at the end of an optional is a complete no-op. It has no effect.
Is ?. a different operator from ? followed by .?
Yes. More specifically, ? has the optional-chaining effect when used in any "postfix expression", including when followed by () (function call), . (member access), and [] (subscript).
Here's my test code:
var myDict: [String: AnyObject] = ["k":"v"]
var a = myDict["k"]
var b = a as String
var c = myDict["k"] as String
Here's my Swift playground in Xcode6-beta6:
According to the rules of type inference, doesn't complaining about c logically contradict not-complaining about b?
I believe that this is a bug. Part of what is going on here is that String is not an object. If you change the first line to:
var myDict: [String: Any] = ["k":"v"]
then everything is fine. So, given that string is not an object, casting a variable of type AnyObject? to a String should definitely yield an error. And, since the compiler has already decided that a is of type AnyObject? it should complain about casting a to a String.
Note that if you change the last line to:
var c = myDict["k"] as NSString
the error goes away supporting the notion that the issue is that String is not an object. You get the same complaint if you put an Int as the value in the array and try to cast that to an Int.
Update:
So the plot thickens. If you don't import Foundation or import something that imports Foundation, then you get additional errors. Without Foundation:
So clearly some of this has to do with the dual nature of Strings as non-objects and NSStrings as objects and the ability to use Strings as NSStrings when Foundation is imported.
This has to do with the fact that Dictionary has two subscript overloads:
subscript (key: Key) -> Value?
subscript (i: DictionaryIndex<Key, Value>) -> (Key, Value) { get }
The first is the familiar one where you pass a key and it gives you an optional of the value; and you can use to set the value on a key.
The second one is less common. I believe DictionaryIndex is a kind of iterator into the dictionary, and you can use it as a subscript to directly get the key-value pair at that iterator.
When the compiler can't find an overload that matches (in this case, the first one doesn't match because it returns an optional, which cannot be cast to non-optional String), it just picks one arbitrarily (well, it seems arbitrary to me anyway) to show in the error. In this place, it picks the second one, which you don't recognize. That's why the error seems weird to you.
This works.
var c = myDict["k"] as AnyObject! as String // "v"
To answer your question, the reason Swift complains could be that you are trying to do these two conversions in one go. Remember, the statement var a = myDict["k"] contains an implicit conversion already. The implied conversion is AnyObject?, so the above would also work like this:
var c = myDict["k"] as AnyObject? as String // "v"
Note that the above would lead to a run time error if the key "k" where not defined. You would allow this to return nil by casting to String?.