Very good point. I was wrong, @tera I now agree with this statement:
However, I maintain that "reference type" vs "value type" is not the important distinction to be focusing on, rather "reference semantics" vs "value semantics".
Very good point. I was wrong, @tera I now agree with this statement:
However, I maintain that "reference type" vs "value type" is not the important distinction to be focusing on, rather "reference semantics" vs "value semantics".
In general case it would be impossible to check if the given thing has a value or reference semantics:
struct Nasty {
private var intValue = 0
let reference: NSMutableString
var value: Int {
get {
if veryComplexCondition() {
return reference.integerValue
} else {
return intValue
}
}
set {
if veryComplexCondition() {
reference.setString("\(newValue)")
} else {
intValue = newValue
}
}
}
}
You can trust the "thing" documentation and pray it's correct.
I donāt want to generally disagree with you, but there are cases that it matters. The only time Iāve used type(of: foo) is AnyClass
is to assert that before assigning it to a weak var foo: AnyObject?
, because using a struct/tuple/enum like that will immediately become nil, even if it has reference semantics.
I wonder why would you use AnyObject
here instead of a stricter type?
(Fair warning that I donāt have a compiler in front of me and Iām typing this on my phone.)
I donāt want to get too deep into the use case, but letās just say that I have an array whose member type is like this:
protocol Element {
var type: Any.Type { get }
var value: /* some protocol thatās adopted by a WeakBox-like type, but also other things */ { get }
}
I use the type
property to determine the type of the value held; I canāt use an associated type because then Swift doesnāt like me accessing the properties (even the marker property type
itself) without already knowing what the associated type is.