The code below compiles and works in swift.
struct TestStruct {
let value: String = "asdf"
}
func iWantAReferenceType(object: AnyObject) {
print(String(describing: object))
}
let o: TestStruct = TestStruct()
iWantAReferenceType(object: o as AnyObject)
I expected this to be a compile error because a struct can never conform to AnyObject. As demonstrated below by code that fails to compile.
protocol Test: AnyObject {
}
//Compile error: because a struct cannot be AnyObject
struct TestStruct: Test {
let value: String = "asdf"
}
I am aware there is some bridging that can happen for certain types such as String. This would convert the value type of a reference type.
print(Mirror(reflecting: "asdf").subjectType) //print: String
print(Mirror(reflecting: "asdf" as AnyObject).subjectType) //print: NSTaggedPointerString
In writing this question I thought to see what the type of the cast object was and it seems it is also bridged in someway.
print(Mirror(reflecting: o).subjectType) //prints: TestStruct
print(Mirror(reflecting: o as AnyObject).subjectType) //prints: _SwiftValue
Why is this type of casting allowed? It seems to be breaking the contract for the function that is expecting a reference type.
I stumbled on this by accident when refactoring some code to support value types, to my surprise it had already been working for value types even though I thought it wouldn't. Is it safe to rely on this behaviour?
This is a feature to facilitate passing to Cocoa. Any struct can be wrapped into a SwiftValue reference type. If you print type(of: object) you'll see the wrapper.
I don't think there is any contract for "expecting a reference type." More importantly, while "value types" and "reference types" exist in Swift, what really matter is value and reference semantics, which are not expressible in the language. You can create value semantics in reference types and reference semantics in value types, so the Swift type system really isn't of any help in that regard.
The important point here is that you only get this unusual behavior if you explicitly request it by asking for as AnyObject. There are very few reason to write that, and if you are, you had better know exactly what you're doing.
Related
I'm new to Swift and trying to decode one of the Apple examples. Could someone please explain what this line is doing ?
#SceneStorage("selection") private var selectedProjectID: Project.ID?
Project is a struct conforming to Codable and Identifiable
Is selectedProjectID of the same type as Project.ID? ?
In general for some type, T, T? is syntactic sugar for Optional<T>.
Optional<T> is defined as an enum with special compiler support for comparisons and assignments to nil. It looks something like this.
enum Optional<Wrapped>
{
case none
case some(wrapped: Wrapped)
}
So when an optional is nil, it's actually .none
In comments you asked:
Does the Project.Id bit mean selectedProjectID will be of explicit type the same as the Project.ID member in the struct ?
The answer is no. selectedProjectID is an instance property (a variable) whose type is Optional<Project.ID>. Project.ID is a type. It does also have a type, a meta-type (the type of a type), but I don't think that's what you mean to ask. I think you're asking if selectedProjectID is same type as the id property that is defined in Project as part of its conformance to Identifiable. And the answer is no, not exactly.
If someProject is an instance of Project, then someProject.id is of type Project.ID, whereas selectedProjectID is of type Optional<Project.ID>.
There is a lot of compiler support extracting, comparing and assigning between optionals and their wrapped type, but strictly speaking they are different types, just as much as Int and Array<Int> are different types.
On the other hand, assuming someProjectID is not nil, then someProjectID! (ie, force-unwrapped) is the same type as someProject.id. Similarly in
if let pID = someProjectID {
...
}
within the if, pID is also the same type as someProject.id
I have a protocol with an optional property.
Most of the types that conform to this protocol will have a matching optional property. However, one has a non-optional property of the same type and name.
protocol SomeProtocol {
var foo: Int? { get }
}
struct StructA: SomeProtocol {
let foo: Int?
}
struct StructB: SomeProtocol {
let foo: Int // Type 'StructB' does not conform to protocol 'SomeProtocol'
}
Pressing Xcode's "Fix - Do you want to add protocol stubs?" button adds the optional version of the property, but the structure now has invalid duplicated variable names:
struct StructB: SomeProtocol {
let foo: Int
var foo: Int? { return foo } // Invalid redeclaration of 'foo'
}
In the { get }-only case, I had assumed that this would "just work" due to the non-optional always satisfying the constraints of the optional, similar to how you can return a non-optional in a function with an optional return type. But apparently that is not the case.
This works the same for functions as well; a protocol's func bar() -> Int? is not satisfied by a conforming type declaring func bar() -> Int.
Is there any way around this issue? I would prefer not to rename the variables or add intermediate getters.
Has this situation been considered for Swift? What is the rational for not allowing a non-optional to satisfy an optional protocol variable?
If the protocol provides a default implementation that returns an optional:
protocol SomeProtocol {
var foo: Int? { get }
}
extension SomeProtocol {
var foo: Int? { return nil }
}
protocol-conforming types can then provide an overriding non-optional version of the variable/function:
struct StructB: SomeProtocol {
let foo: Int
}
I found this discussed on the Swift Evolution forum:
At the first glance I thought there is a rule that allows us to satisfy protocol requirements with non-optional types, but this resulted in an error. Only after further investigation I noticed that a default implementation must exist in order to 'kind of override' the requirement with a non-optional version.
https://forums.swift.org/t/how-does-this-rule-work-in-regard-of-ambiguity/19448
This Swift team also discusses allowing non-optional types to satisfy optional-value protocols:
Would it make any sense to allow protocol requirement satisfaction with non-optional types, like with failable init's? (Probably with some implicit optional promotion.)
Yep, totally! Except for the part where this changes the behavior of existing code, so we'd have to be very careful about it. This is considered part of [SR-522] Protocol funcs cannot have covariant returns
which is tracked on Stack Overflow here:
Why can't a get-only property requirement in a protocol be satisfied by a property which conforms?
The extension-with-default-implementation solution offered by pkamb is helpful in terms of getting the compiler to recognize conformance, but you need to be aware of the strange behavior this can produce.
An object of the newly conforming type will return a different value depending on what type you cast it to (this also includes passing as to a parameter whose type is the protocol):
let bar = StructB(foo: 7)
let baz: SomeProtocol = bar
bar.foo // evaluates to 7
baz.foo // evaluates to nil (surprise!)
As someone recently commented on a related Swift bug ticket: "This can be quite surprising and perhaps could be considered a bug of its own?"
It definitely tripped me up.
I was playing around with some code in swift and encountered one interesting case.
Lets start with a little preamble: suppose you create some optional variables:
let a: String? = "abcd"; let b: Int? = 4
print(
"Type of \(a) is \(type(of: a))" //Type of Optional("abcd") is Optional<String>
"Type of \(b) is \(type(of: b))", //Type of Optional(4) is Optional<Int>
separator: "\n"
)
Then you force unwrap so types of au and bu are not optional.
let au = a!; let bu = b!
print(
"Type of \(au) is \(type(of: au))", //Type of abcd is String
"Type of \(bu) is \(type(of: bu))", //Type of 4 is Int
au + String(bu), //abcd4
separator: "\n"
)
Seem reasonable, but things start to go weird, when you try to apply same code to Optional<Any>:
let a: Any? = "abcd"; let b: Any? = 4
let au = a!; let bu = b!
print(
"Type of \(a) is \(type(of: a))", //Type of Optional("abcd") is Optional<Any>
"Type of \(b) is \(type(of: b))", //Type of Optional(4) is Optional<Any>
"Type of \(au) is \(type(of: au))", //Type of abcd is String
"Type of \(bu) is \(type(of: bu))", //Type of 4 is Int
//au + String(bu),
separator: "\n"
)
But now if you try to to do same concatenation au + String(bu), swift will produce compilation error, even though these two variables are known to be of some concrete type, as reported by swift itself.
The error is:
error: protocol type 'Any' cannot conform to 'LosslessStringConvertible' because only concrete types can conform to protocols
This certainly looks like a bug, isn't it. Please, share your opinion.
As others have noted, type(of:) is the dynamic, runtime type of a value. The compiler relies only on the static, provable type of a value. In the code above, the only thing that the compiler can prove is that au will be of type Any. One of the many types that conform to Any is String, but the compiler doesn't know that in all possible code paths, the value really will be a String.
Since there is no func + (Any, String) overload, this can't compile.
Note that Any? is a bizarre and dangerous type. The problems with it aren't the cause of this example, but the way that it interacts with Optional promotion can lead to significant ambiguity and confusion. Every type in Swift can be implicitly promoted to an Optional of that type. And every type in Swift can be implicitly cast to Any. Combining those two facts means that Any can be implicitly promoted to Any?, or Any??, or Any???, etc., and yet all of those are also subtypes of Any. This can create all kinds of subtle headaches. You should strongly avoid using Any; it is very seldom the right tool. But you should even more careful of allowing Any? to show up in your code. It is an indication that something has probably gone wrong.
type(of: T) method gets runtime type of any variable. That is why you are seeing (type(of: au) as String. But Swift will not allow implicit type casting for safety reasons. That is the reason you can not add Int and Double without casting in Swift. You need to cast explicitly for your code to work.
type(of: T) Returns the dynamic type of a value.
You can use the type(of:) function to find the dynamic type of a value,
particularly when the dynamic type is different from the static type. The
static type of a value is the known, compile-time type of the value. The
dynamic type of a value is the value's actual type at run-time, which
can be a subtype of its concrete type.
This explanation is taken from comment above type(of: T) function. Do Cmd+click on type(of: T) in Xcode to read more
init?(plistRepresentation : AnyObject){
switch plistRepresentation{
case "viewing":
self = .viewing
}
}
The above code generates "Expression pattern of type 'String' cannot match values of type 'AnyObject'" error. But the moment I add "as Sttring"
init?(plistRepresentation : AnyObject){
switch plistRepresentation{
case "viewing" as String:
self = .viewing
}
}
the error goes away.. Can anyone explains to me how this works? It looks kinda confusing to me.
Thanks
AnyObject is a generalise type that includes all type of object type like array, dictionary, set, string, etc.
AnyObject refers to any instance of a class, and is equivalent to id in Objective-C. It's useful when you specifically want to work with a reference type, because it won't allow any of Swift's structs or enums to be used.
Swift's switch want a specific type to match the case that's the reason when you put as String the error goes away.
More detail on AnyObject can be found here
I understand the difference between String! type and String? type. But what about String type? How does it differs from String! and String? in swift? Does String! type identical to String type?
Say, I have a class like this:
class Person {
private var _name: String!
var name: String {
return _name
}
init(name: String) {
_name = name
}
}
There is no compiler error, looks like String type is identical to String! type. But I am not sure...
String and String! are not identical. There is just happens to be enough sugar in the language to convert between them. Similarly there is sugar in the language to convert between String and String? (but not in reverse).
Start with the basics. There is String. Unless there is some strong reason, you should use String when you mean a string of characters. Everything else is "more stuff" and you shouldn't add it unless you need it.
There is Optional<String>. This is just an enum with two cases, one with a value, and one without a value:
public enum Optional<Wrapped> : _Reflectable, NilLiteralConvertible {
case None
case Some(Wrapped)
// ...
}
There is a postfix operator ! for Optional which will return Wrapped if it's available, and crash if it is not. So far, no magic. This is stuff you could build yourself.
There are are few pieces of magic around Optional. First, the type Wrapped? is magically converted to Optional<Wrapped> by the compiler (for any Wrapped). This is just syntactic sugar. The two notations are identical. Second, there is optional-chaining with the ?. "operator" (it's not really an operator; it's part of the language and you couldn't build it yourself). And then there's optional promotion. Any type Wrapped can be automatically and implicitly converted to Wrapped? if needed. There are are few other pieces of magic around Optional like if-let syntax, and there's nil which is a synonym for Optional.None (I believe they're actually identical). But Optional really is just a generic type, implemented as an enum. It's just a type the compiler knows special things about.
Then there is ImplicitlyUnwrappedOptional<Wrapped>. This is also just an enum (in Swift 2.2; this will change in Swift 3).
public enum ImplicitlyUnwrappedOptional<Wrapped> : _Reflectable, NilLiteralConvertible {
case None
case Some(Wrapped)
// ...
}
This is not the same as Optional and it is not the same as Wrapped. It's a completely different type. But it also has some magic associated with it. First, the type Wrapped! is syntactic sugar for ImplicitlyUnwrappedOptional<Wrapped>. Again, it's just sugar. The two are the same (in Swift 2.2, not in Swift 3). Next, if IUO<Wrapped> is found in a place that Wrapped is expected, it will automatically be converted to Wrapped or crash if there is no value. If it is found in a place that Wrapped? is expected, it will automatically be converted to Wrapped?. Those are magical, and it's why sometimes String and String! seem to be the same type. That's just the compiler magically "making it work" for you by adding an invisible conversion step. It doesn't mean they're really the same type.
IUO is mostly useful in bridging to certain Objective-C patterns, especially involving Storyboards, and should be avoided outside of those situations. Even in those situations, IUO is just there for convenience. You could do all the same things using regular Optionals, you'd just have to check them with if-let more often. Using Optionals is much safer than using IUO. It's easy to think "I know for certain this value will always be set before it is used." And just this week I chased down a crasher due to being wrong about that. There's a difference between "it should be" and "it must be." But, being totally safe with Optionals in Storyboards could be very inconvenient and might mask some bugs (by doing nothing rather than crashing), so that's the most common place for IUO.
IUO properties used to be valuable for dealing with failable init methods. That's no longer a problem in Swift 2.2, so that use has gone away. The last "pure Swift" use that I run into is when you must pass self to the initializer of something you store as a property (you can't pass self at that point because all your properties have been initialized). That's an unfortunate use-case and very messy, and I hope we come up with a fix for it. Outside of these kinds of cases, you should avoid Implicitly Unwrapped Optionals.
String and String! are same and different at the same time. If you declare let or var as String, you will have to set some value at init method. If you declare it as String! you can set value when you want but you must do it before reading this value.
So, if your _name will be nil, your app will crash.
If you declare it as String, compiler guarantees that _name != nil before the first reading. If you declare it as String!, you should guarantee it.
This things have same type because of this:
var test1: String = "test"
var test2: String! = "test"
if test1 is String { // True
print("test1 is String")
}
if test2 is String { // True
print("test2 is String")
}
This types are equal but this things are different
Note the difference between these two functions:
func f() {
let x: String? = nil
guard let y: String = x else {
print("failed")
return
}
}
func g() {
let x: String? = nil
guard let y: String! = x else {
print("failed")
return
}
print(y.dynamicType, y)
}
f() # failed
g() # Optional<String> nil
You are better to read swift documentation than any answer here. Properly undestandig swift's type system is very important, so do it first.
both String! and String? are optional types.
Using String? requires you to test whether the value is nil (.None) or a value (.Some). For example using guard statements or if-let clauses.
String! is an optional that is assumed to be non-nil and is unwrapped automatically. This allows you to write cleaner-looking code and avoid unwrapping wherever the value is used. BUT: if your value is nil a fatal error will occur.