I encountered an issue regarding type checking in a relatively simple case. Am I missing something here? Maybe some nuance between Self within extensions and inheritance?
Or is it actually a bug?
open class Gift {}
struct Box<Contents> {
var contents: Contents
}
extension Gift {
var box: Any { Box<Self>(contents: self) }
// Cannot convert value of type 'Gift' to expected argument type 'Self'
}
Here, both removing <Self> and adding self as! Self helps, resulting in different types of Box. Considering the latter is preferable for my case, can as! actually fail here? Is there a better workaround?
my understanding is that this is the same reason this is not allowed:
class Gift {}
extension Gift
{
var box:[Self] { [self] }
}
Swift version 5.10 (swift-5.10-RELEASE)
Target: x86_64-unknown-linux-gnu
<stdin>:5:9: error: covariant 'Self' or 'Self?' can only appear at the top level of property type
var box:[Self] { [self] }
^
the Self loses its dynamicness when it is bound to a generic, which is why you cannot create Box<Self> even if you erase it later.
class Gift {
func give() {
print(self) // app.Gift
print(Self.self) // Gift
print(self as Self) // error: 'Gift' is not convertible to 'Self'
print(self as! Self) // app.Gift
}
}
Probably prevents compiler blowout than anything related to variance.
The type of self is Gift, not Self, except for in the special case of a method that returns Self. You probably should just write Gift instead of Self unless you really mean Self.
In general the dynamic Self type (what you get when you write Self in a class; other nominal types are fine) is not well-designed and is mostly a compatibility hack for Objective-C.
Yeah, declaring a class as final doesn’t actually change the behavior of the dynamic Self type if one is stated, it just requires it in fewer situations.
The protocol Self is a generic parameter which makes everything nice and neat. The dynamic Self inside a class is its own thing.
Formally, it's a value-dependent type, like an opened existential. Probably the best model for such a feature would be something like this:
Treat class methods as having an implicit Self generic parameter that is subject to a superclass requirement, just like Self behaves in protocols today (except it has a conformance requirement of course).
A value of class type like C is really an existential any C which is opened when you call a method on it.
Instead, dynamic Self is a special case today. This causes some odd behaviors and other problems, for example because the association between the type and the value isn't really tracked, we cannot inline or specialize code that uses dynamic Self (imagine you inline two method calls that both involve Self into the same function; how do you tell which Self is which self?).
A representation change could probably fix most of these problems without breaking compatibility.
If we ever do another source-break -swift-version mode again, we could also change self to have dynamic Self type in all class methods, not just those returning Self, but the fallout might be too great. Another possibly massively breaking change is to interpret Self as the static class type inside a final class.
There are also some soundness issues in conformance checking related to this weird modeling of dynamic Self. In general, the interaction between conformances and subclassing is hard to get right, and in my personal opinion, future languages in the Swift family should not allow subclassing.
This behavior, combined with the invisible difference between protocol-based and type-based dispatch, are some of the biggest obstacles affecting anyone migrating to Swift from other OO languages. There are too many variables affecting how a method call is bound in Swift, and I wouldn’t be surprised if this has inadvertently steered the Swift ecosystem away from classes and toward protocols. I’m also curious if this is will become an issue for C++ interop. The binding rules for C++ are straightforward; virtual methods are late-bound, everything else is early-bound. How much extra mental work does Swift impose, and will that discourage porting code from C++?
I’m not sure what Swift does any differently here except that class methods are virtual by default and explicitly declared final otherwise. (The dynamic Self type does not change class method dispatch semantics FWIW).
final class Gift {}
struct Box<Contents> {
var contents: Contents
}
extension Gift {
var box: Any { Box<Self>(contents: a()) } // Cannot convert value of type 'Gift' to expected argument type 'Self'
func a() -> Self {
self
}
}
This error is even more confusing, it still stays on the line with box declaration
today i discovered another compiler bug (this one a miscompile!) related to dynamic Self, the details are in the GitHub issue below, but long story short required initializer inheritance seems to be broken on 5.10 and on main.
i’m not sure if my test program is unsound or if the compiler is missing a diagnostic here. however, right now it compiles and behaves differently between debug mode and release mode.