On 13.05.2016 9:45, Patrick Smith wrote:
Could protocol Self change to just the first behaviour for classes?
If a conformance absolutely needs to have a method returning ‘only me but not
my subclasses’, then it sets that conforming method to be final.
Hm.. Do we *need* to change `->Self` behavior? It actually depends on what
such requirement will mean for classes. Right now it is '->return instance
of self class'. If we all agree that it should means '->return instance of
self class or of any base class' - then we obviously can require such a
change.
On 13 May 2016, at 4:38 PM, Vladimir.S <[email protected]> wrote:
The proposed StaticSelf when used as `->StaticSelf` in protocol means ‘myself or
my some *base* class’. I.e. if this requirement was implemented in one of base
classes, any subclass automatically conforms to the protocol as it has `->(myself
or some base class)` in his hierarchy.
This is the difference with `->Self` in protocol which requires 'myself'.
On 13.05.2016 7:21, Patrick Smith via swift-evolution wrote:
I didn’t really understand some of the lead in discussion examples
regarding protocols A and B each being interwoven, but I would prefer to
see StaticSelf only used for concrete types, and protocols only to use
Self. If Self has problems with non-final classes, then maybe how it
works in protocols could change. A class could interpret a protocol’s
‘Self’ as ‘myself or my subclasses’?
Maybe instead of introducing StaticSelf it could be renamed simply Self,
and ‘Self’ as used in protocols could change to something else?
‘Instance’ perhaps?
On 13 May 2016, at 12:21 PM, Joe Groff via swift-evolution
<[email protected]> wrote:
On May 12, 2016, at 5:49 PM, Matthew Johnson via swift-evolution
<[email protected]> wrote:
The invariant StaticSelf identifier will always refer to A, unlike
Self, which is covarying and refers to the type of the actual
instance. Since multiple inheritance for non-protocol types is
disallowed, this establishes this invariant type identifier with no
possibility for conflict.
Consider the following example, under the current system:
protocol StringCreatable {
static func createWithString(s: String) -> Self
}
extension NSURL: StringCreatable {
// cannot conform because NSURL is non-final
// error: method 'createWithString' in non-final class 'NSURL' must
return `Self` to conform to protocol 'A'
}
Introducing a static, invariant version of Self permits the desired
conformance:
protocol StringCreatable {
static func createWithString(s: String) -> StaticSelf
}
extension NSURL: StringCreatable {
// can now conform conform because NSURL is fixed and matches the
static
// type of the conforming construct. Subclasses need not
re-implement
// NOTE: the return type can be declared as StaticSelf *or* as
NSURL
// they are interchangeable
static func createWithString(s: String) -> StaticSelf {
// ...
} }
As I've noted before, I don't think this makes sense to encode in the
protocol. `Self` is already effectively invariant within a protocol.
If a protocol doesn't have the foresight to use StaticSelf, then you
still have the same problems retroactively conforming class
hierarchies to the protocol. Whether a conformance is inherited or not
feels more natural as a property of a conformance, not something that
can be legislated a priori by a protocol definition.
Something like StaticSelf might still be useful as shorthand within a
class definition with a long-winded name, though `StaticSelf` feels
kind of long as a shortcut to me.
-Joe _______________________________________________ swift-evolution
mailing list [email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing
list [email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
