I have a generic struct with a couple of functions that just print a string.
I added an extension to that struct with a specialization for a specific type on the generic and re-implemented the functions to print a different string.
If I call these specialized functions on an instance of the struct directly then it correctly calls the specialized versions of the function I call if I instantiate the generic with the matching type.
If, however, define a computed property in the struct definition whose getter or setter call the same functions then the specialized version of the function is never called even when the computed property is accessed on an instance of the struct instantiated for the specialized type.
This didn't match my expectation so I don't know if my expectations are wrong, it's a bug in Swift 5.3 (Xcode 12b2), or simply a limitation in Swift.
Here's a super simple example that does nothing but shows the issue:
// macOS playground source
// swift 5.3, Xcode 12b2
import Cocoa
struct Foo<A> {
var value: A? {
get {
getter()
return nil
}
set { setter() }
}
func getter() {
print("internal getter A")
}
func setter() {
print("internal setter A")
}
}
// make a specialization for Strings but change the string printed out
extension Foo where A == String {
func getter() {
print("External getter A")
}
func setter() {
print("External setter A")
}
}
print("\nFirst an Int instance, functions first then computed property\n")
var i = Foo<Int>()
i.getter()
i.setter()
i.value = 42
String(describing: i.value)
print("\nNow the string specialization, functions first then computed property\n")
var s = Foo<String>()
s.getter()
s.setter()
s.value = "hello world"
String(describing: s.value)
print("\n\nyou can see that the last two calls to the computed property in the second example used the *internal* implementation of the `getter()` and `setter()` functions instead of the external specialized version")
Curious if I should report this as a bug or if it's a design limitation or ???
I just wasted a lot of time chasing down a bug because of this :-/
TIA
oh, the output would help:
First an Int instance, functions first then computed property
internal getter A
internal setter A
internal setter A
internal getter ANow the string specialization, functions first then computed property
External getter A
External setter A
internal setter A
internal getter Ayou can see that the last two calls to the computed property in the second example used the internal implementation of the
getter()
andsetter()
functions instead of the external specialized version