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.
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution