I don't understand.
Right now we are allowed to have Optional(Self) :
protocol A {
func g()->Self?
}
class B: A {
func g()->Self? {return self}
}
print(B().g()) //Optional(main.B)
How do you want to divide your `->Self?` and this currently possible
`->Self?` ?
But I do like the idea to separate meaning of `Self` in protocol with some
marker.. What about `->?Self` and `->!Self` - no confusing with Optional<>
On 13.05.2016 14:21, LM via swift-evolution wrote:
The other advantage of Self! over StaticSelf is that in code completion,
Self, Self? Self! Will come together, giving people a quick tool to
discover/remind themselves of the semantic difference right at the point of
use.
It might also address Joe's comment about StaticSelf not being much of a
shortcut.
On May 13, 2016, at 1:15 PM, LM <[email protected]
<mailto:[email protected]>> wrote:
Considering the precedent of using ! and ? in swift, could it be that:
Self! would designate what is known for sure, the invariant compile time
type of self
Self? Would designate the yet unknown (*optional* if you will) covariant
type of self
Regards
LM
(From mobile)
On May 13, 2016, at 3:59 AM, Xiaodi Wu via swift-evolution
<[email protected] <mailto:[email protected]>> wrote:
I like the way the motivation for this feature has been explained here.
Now that the reasoning behind it is evident, I have to say I'm leaning
towards the "InvariantSelf" name--after all, you describe this feature
in the title as "an invariant self."
On Thu, May 12, 2016 at 7:49 PM, Matthew Johnson via swift-evolution
<[email protected] <mailto:[email protected]>> wrote:
Erica Sadun and I have written a proposal are following up the
recent discussion thread "[RFC] #Self” with a proposal to introduce
StaticSelf, an invariant Self.
The recent discussion can be found
here: http://thread.gmane.org/gmane.comp.lang.swift.evolution/16565
The proposal can be found
here:
https://github.com/anandabits/swift-evolution/blob/static-self/proposals/NNNN-static-self.md
We look forward to continuing the discussion. We plan to submit a
PR in the near future after incorporating your final feedback.
Thanks,
Matthew
Introducing StaticSelf, an Invariant Self
* Proposal: TBD
* Authors: Matthew Johnson <https://github.com/anandabits>, Erica
Sadun <https://github.com/erica>
* Status: TBD
* Review manager: TBD
Introduction
This proposal introduces a new keyword that provides consistent
invariant type semantics in all contexts.
/The Swift-evolution thread about this topic can be found
here: [RFC] #Self
<http://thread.gmane.org/gmane.comp.lang.swift.evolution/16565>/
Motivation
The distinction between covariant and non-covariant type references
come into play when
conforming non-final classes to protocols. Fixing a protocol
requirement to a covarying type
means that a method returning |Self| must be overriden by all
subclasses in order to return
the correct, matching type.
This proposal builds on the covariant construct |Self| accepted
in SE–0068
<https://github.com/apple/swift-evolution/blob/master/proposals/0068-universal-self.md>
to introduce an invariant type identifier. It enables protocol
declarations to consistently
refer to a type that is fixed at compile time. This ensures that
subclasses can inherit
protocol implementations without having to re-implement that code at
each level of
inheritance.
Under this proposal, a new identifier keyword is fixed in use /at
the point of protocol conformance/
to the static type of that construct.
|class A: MyProtocol|
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 { // ... } }|
Additional Utility
The utility of |StaticSelf| is not limited to protocols. A secondary
use enables code to refer to the lexical context’s current type
without explicitly mentioning its name. This provides a useful
shortcut when referencing static type members with especially long
names and when re-purposing code between types.
|class StructWithAVeryLongName { static func foo() -> String { // ...
} func bar() { // ... let s = StaticSelf.foo() // } }|
Detailed Design
This proposal introduces |StaticSelf|, a new keyword that may be
used in protocols to refer to the invariant static type of a
conforming construct. |StaticSelf| may also be used in the lexical
context of any type declaration. In such use, the keyword is
identical to spelling out the full name of that type.
Impact on existing code
Being additive, there should be no impact on existing code.
Alternatives considered
The keyword is not fixed at this time. Alternatives that have been
discussed include |StaticType|, |InvariantSelf|, |SelfType|,
or |Type|. The community is welcome to bikeshed on the most clear
and concise name for this keyword.
_______________________________________________
swift-evolution mailing list
[email protected] <mailto:[email protected]>
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected] <mailto:[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
