Are there reasons that prevent using `Self` as a synonym for an instance's type name?
Consider:
struct MyStruct {
static func foo() { print("foo") }
func bar() {
MyStruct.foo() // works
self.dynamicType.foo() // works
Self.foo() // error
}
}
Obviously, you can always name a type directly or use `self.dynamicType` but
neither solution does any favors for readability. Both approaches obscure intent,
especially as type names grow large: `MyExtremelyLargeTypeName.staticMember`,
for example. Plus, as Kevin B pointed out to me, `self.dynamicType.classMember`
and `TypeName.classMember` may not be synonyms in class types with non-final members.
I'd like to see `Self.staticMember` introduced as a synonym for `TypeName.staticMember`.
Thoughts?
I'm kind of struggling with how best to design this. Here's the most coherent design I've been able to come up with so far.
* Adopt the proposal to no longer require `.self` on types to get the type instance. Using a type name in expression context gives you the type instance.
* Every variable `foo` has a typealias attached to it, `foo.Self`. This is the static (compile-time declared or inferred) type of that instance. You can use it anywhere you can use a type name, including in declarations. If it's used in an expression, it becomes the type instance of the variable's static type.
* Every variable `foo` has a special typealias attached to it, `foo.DynamicSelf`. This is the dynamic (runtime assigned) type of that instance. In theory you can use it anywhere you can use a type name, though in practice there are probably significant limitations. If it's used an expression, it become the type instance of the variable's dynamic type.
* A bare `Self` or `DynamicSelf` is a shorthand for `self.Self` or `self.DynamicSelf`.
`DynamicSelf` subsumes the roles of both the old `Self` and `dynamicType`. `Self` is both an alias for the declared type and a way to get its type instance.
This gives us a number of new abilities:
Self.classMember() // Instead of ReallyLongClassName.classMember()
foo.Self.classMember() // Likewise, but for a different variable
let self2: Self // Match the static type of self
let foo2: foo.Self // Match the static type of a different variable
DynamicSelf.classMember() // Instead of self.dynamicType.classMember()
foo.DynamicSelf.classMember() // Likewise
let self3: DynamicSelf // Match the dynamic type of self
let foo3: foo.DynamicSelf // Match the dynamic type of a different variable
// (Those would probably require certain restrictions, like the base variable has to be
// immutable and the assignment has to come from a function returning a DynamicSelf
// derived from `self`/`foo`.)
// Make promises about matching dynamic types of parameters besides `self`:
func tenMinutesAfter(date: NSDate) -> date.DynamicSelf {
return date.adding(10 * 60) // Note that `adding(_: NSTimeInterval)` returns DynamicSelf
}
// Possible alternative to generic syntax:
func removingCommonPrefix(_ one: Collection, _ two: Collection) -> (one.Self.SubSequence, two.Self.SubSequence) where one.Self.Element == two.Self.Element, one.Self.Element: Equatable {
for (oneIndex, twoIndex) in zip(one.indices + [one.endIndex], two.indices + [two.endIndex]) {
if oneIndex == one.endIndex || twoIndex == two.endIndex || one[oneIndex] != two[twoIndex] {
return (one.suffixFrom(oneIndex), two.suffixFrom(twoIndex))
}
}
fatalError("Can't get here")
}
The only disadvantage I see to this approach is that code which currently uses `Self` will be longer. But there may be other problems as well. I'm not entirely sure I have a good handle on the existing `Self` vs. `dynamicType`; it's possible the connection I see between them is spurious or ill-defined.
By the way, an alternative would be to leave the dynamic type as `Self` and call the static type `Type`, which I *think* would generalize the existing notion of the metatype being accessible as `Type`. In other words:
Type.classMember() // Instead of ReallyLongClassName.classMember()
foo.Type.classMember() // Likewise, but for a different variable
let self2: Type // Match the static type of self
let foo2: foo.Type // Match the static type of a different variable
Self.classMember() // Instead of self.dynamicType.classMember()
foo.Self.classMember() // Likewise
let self3: Self // Match the dynamic type of self
let foo3: foo.Self // Match the dynamic type of a different variable
// (Those would probably require certain restrictions, like the base variable has to be
// immutable and the assignment has to come from a function returning a Self
// derived from `self`/`foo`.)
// Make promises about matching dynamic types of parameters besides `self`:
func tenMinutesAfter(date: NSDate) -> date.Self {
return date.adding(10 * 60) // Note that `adding(_: NSTimeInterval)` returns Self
}
// Possible alternative to generic syntax:
func removingCommonPrefix(_ one: Collection, _ two: Collection) -> (one.Type.SubSequence, two.Type.SubSequence) where one.Type.Element == two.Type.Element, one.Type.Element: Equatable {
for (oneIndex, twoIndex) in zip(one.indices + [one.endIndex], two.indices + [two.endIndex]) {
if oneIndex == one.endIndex || twoIndex == two.endIndex || one[oneIndex] != two[twoIndex] {
return (one.suffixFrom(oneIndex), two.suffixFrom(twoIndex))
}
}
fatalError("Can't get here")
}
But I'm even *less* certain that `someVariable.Type` and `SomeClass.Type` are similar in any real sense, so I have my doubts about the wisdom of that one.
···
--
Brent Royal-Gordon
Architechies