[swift-evolution] [Pitch] Tweak `Self` and introduce `Current`
Anton Zhilin
antonyzhilin at gmail.com
Sat Jan 7 13:00:22 CST 2017
I have no problem with the syntax proposed in SE-0068.
The rationale briefly mentions that dynamic Self will be used anywhere
inside the class body. I think that the possibilities that open with this
decision should be mentioned in the proposal.
We can say that non-final classes, apart from that they can also have
instances of themselves, behave very much like protocol existentials. They
couple requirements and “default implementation”. Like existential
protocols, they can’t have associated types. SE-0068 expands abilities of
classes and allows their requirements to contain Self. “Default”
implementation is mandatory, as usual. Example of code that will be
possible:
// Compiles now
protocol P {
init()
func foo(_ x: Self) -> Self
}
extension P {
func foo(_ x: Self) -> Self {
print(Self.self)
return Self.init()
}
}
struct S : P { }
let x = S()
_ = x.foo(x) // prints "S"
// Will compile after implementation of SE-0068
class A {
required init() {
}
func foo(_ x: Self) -> Self {
print(Self.self)
return Self.init()
}
}
class B : A { }
let y = B()
_ = y.foo(y) // prints "B"
I find that consistent enough. The annoyance is that we don’t and won’t
have the ability to implement protocol requirements with Self in classes
without Self. This is an error:
protocol P {
func foo() -> Self
}
class A {
func foo() -> A { ... }
}
class B : A {
override func foo() -> B { ... }
}
The fact that we can’t get rid of Self in implementation is an abstraction
leak.
As a side note, seeing Self.self, I really look forward to refactoring Self,
self, Type, Protocol and MemoryLayout.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170107/e0b9741f/attachment.html>
More information about the swift-evolution
mailing list