Well, I believe I understand now what *you mean* under #Self. OK. Thank you
for clarifications.
In my terminology 'this' could be called BaseSelf. Your "thing" just can
not be called #Self.
IMO in initial proposal #Self means not more than placeholder for the
concrete type name(inside type declaration or inside protocol).
You propose just something different, more advanced than initial #Self, you
propose not some static "thing" but extended behavior if #Self is a return
type of protocol requirement.
I strictly against to couple the initial proposal of #Self and your
proposal for extended features (for protocol conformance of `->#Self`).
Please be clear and obvious regarding the name of that feature. I really
think the behavior you propose can not be called #Self(or Type)
What I suggest: de-couple these proposals to:
a) initial proposal of #Self as placeholder for concrete type name. Choose
the name for it. Probably StaticSelf, or Type, or somehting else
b) your proposal for BaseSelf feature. I'll definitely support it with just
name changed to clearly reflect its propose.
On 11.05.2016 18:58, Matthew Johnson wrote:
'f' would return E for E, F and G. Because the conformance is declared
by E the requirement to return #Self is fixed as an invariant
requirement to return E for all potential subclasses.
Probably you(we) need another proposal, like BaseSelf (or SuperSelf)
that means "this class or any its base class", then I understand how
such a `f()->BaseSelf` protocol requirement can be applied to E
class and also be true for F&G classes (as f() inherited from base
class will return instance of E which is base for both).
This is exactly what #Self (or Type) does. The behavior you have been
describing is the behavior of Self which already exists.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
