To focus SE-0068 and narrow its scope, I removed the `#Self` part of the proposal. This offered compile-time substitution of the defining type for a related #Self literal:
A further static identifier, #Self expands to static type of the code it appears within, completing the ways code may want to refer to the type it is declared in.
#Self expands to the static type of the code it is declared within. In value types, this is always the same as Self. In reference types, it refers to the declaring type. #Self will offer a literal textual replacement just like #file, etc.
At Chris's suggestion, I'm starting a new SE thread to see whether there remains any interest for including #Self in the language. I'm personally happy with the SE-0068 outcome but I didn't want to undercut anyone like Timothy Wood who had originally spoken up for its inclusion.
Can you clarify where would self would be allowed?
* property declarations
* method signatures
* method and computed property bodies
* all of the above
I would like to see this and allowed in all of the above.
We should also consider allowing this in protocol requirements. It would not covary like Self does for return types, instead being fixed by the class that declares conformance.
···
Sent from my iPad
On May 10, 2016, at 8:15 AM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:
To focus SE-0068 and narrow its scope, I removed the `#Self` part of the proposal. This offered compile-time substitution of the defining type for a related self literal:
A further static identifier, self expands to static type of the code it appears within, completing the ways code may want to refer to the type it is declared in.
self expands to the static type of the code it is declared within. In value types, this is always the same as Self. In reference types, it refers to the declaring type. self will offer a literal textual replacement just like #file, etc.
At Chris's suggestion, I'm starting a new SE thread to see whether there remains any interest for including self in the language. I'm personally happy with the SE-0068 outcome but I didn't want to undercut anyone like Timothy Wood who had originally spoken up for its inclusion.
On 10 May 2016, at 11:15 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:
To focus SE-0068 and narrow its scope, I removed the `#Self` part of the proposal. This offered compile-time substitution of the defining type for a related self literal:
A further static identifier, self expands to static type of the code it appears within, completing the ways code may want to refer to the type it is declared in.
self expands to the static type of the code it is declared within. In value types, this is always the same as Self. In reference types, it refers to the declaring type. self will offer a literal textual replacement just like #file, etc.
At Chris's suggestion, I'm starting a new SE thread to see whether there remains any interest for including self in the language. I'm personally happy with the SE-0068 outcome but I didn't want to undercut anyone like Timothy Wood who had originally spoken up for its inclusion.
As a compile-time substitution, it could be used in any and all of the examples in your bullet list as a literal text replacement..
Quick rundown:
struct A {
...self... // self is substituted by A
}
class B {
...self... // Self is substituted by B
}
class C {
... self... // Self is substituted by C, which is the defining type at compile time
}
I'm stepping away from endorsing or pushing this forward. If you want to pick this up and run with it, it's yours.
-- E
···
On May 10, 2016, at 8:34 AM, Matthew Johnson <matthew@anandabits.com> wrote:
Can you clarify where would self would be allowed?
* property declarations
* method signatures
* method and computed property bodies
* all of the above
I would like to see this and allowed in all of the above.
We should also consider allowing this in protocol requirements. It would not covary like Self does for return types, instead being fixed by the class that declares conformance.
Sent from my iPad
On May 10, 2016, at 8:15 AM, Erica Sadun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
To focus SE-0068 and narrow its scope, I removed the `#Self` part of the proposal. This offered compile-time substitution of the defining type for a related self literal:
A further static identifier, self expands to static type of the code it appears within, completing the ways code may want to refer to the type it is declared in.
self expands to the static type of the code it is declared within. In value types, this is always the same as Self. In reference types, it refers to the declaring type. self will offer a literal textual replacement just like #file, etc.
At Chris's suggestion, I'm starting a new SE thread to see whether there remains any interest for including self in the language. I'm personally happy with the SE-0068 outcome but I didn't want to undercut anyone like Timothy Wood who had originally spoken up for its inclusion.
I think it would be surprising if self produced the name of the enclosing static type: Self produces the dynamic type, and we’d want to preserve consistency if it were named self.
-Chris
···
On May 10, 2016, at 7:50 AM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:
As a compile-time substitution, it could be used in any and all of the examples in your bullet list as a literal text replacement..
Quick rundown:
struct A {
...self... // self is substituted by A
}
class B {
...self... // Self is substituted by B
}
class C {
... self... // Self is substituted by C, which is the defining type at compile time
}
A.implementingClass() and B.implementingClass() would both return A.self
I suspect that case 1 is the easiest to discuss, but all three make sense to me personally. Perhaps they should be separate proposals, perhaps not. Also, I’m not sure if the implementation would have any ABI/resilience concerns (particularly for #2 and #3 where when crossing module boundaries.
-tim
···
On May 10, 2016, at 7:50 AM, Erica Sadun <erica@ericasadun.com> wrote:
As a compile-time substitution, it could be used in any and all of the examples in your bullet list as a literal text replacement..
Quick rundown:
struct A {
...self... // self is substituted by A
}
class B {
...self... // Self is substituted by B
}
class C {
... self... // Self is substituted by C, which is the defining type at compile time
}
I'm stepping away from endorsing or pushing this forward. If you want to pick this up and run with it, it's yours.
-- E
On May 10, 2016, at 8:34 AM, Matthew Johnson <matthew@anandabits.com <mailto:matthew@anandabits.com>> wrote:
Can you clarify where would self would be allowed?
* property declarations
* method signatures
* method and computed property bodies
* all of the above
I would like to see this and allowed in all of the above.
We should also consider allowing this in protocol requirements. It would not covary like Self does for return types, instead being fixed by the class that declares conformance.
Sent from my iPad
On May 10, 2016, at 8:15 AM, Erica Sadun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
To focus SE-0068 and narrow its scope, I removed the `#Self` part of the proposal. This offered compile-time substitution of the defining type for a related self literal:
A further static identifier, self expands to static type of the code it appears within, completing the ways code may want to refer to the type it is declared in.
self expands to the static type of the code it is declared within. In value types, this is always the same as Self. In reference types, it refers to the declaring type. self will offer a literal textual replacement just like #file, etc.
At Chris's suggestion, I'm starting a new SE thread to see whether there remains any interest for including self in the language. I'm personally happy with the SE-0068 outcome but I didn't want to undercut anyone like Timothy Wood who had originally spoken up for its inclusion.
I’m not sure I understand this comment -- if self should mean the same as Self, why would it get added? My whole point in suggesting self was that it mirrored #file and #line in that it was a compile time replacement of some static information.
-tim
···
On May 10, 2016, at 8:56 AM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:
On May 10, 2016, at 7:50 AM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:
As a compile-time substitution, it could be used in any and all of the examples in your bullet list as a literal text replacement..
Quick rundown:
struct A {
...self... // self is substituted by A
}
class B {
...self... // Self is substituted by B
}
class C {
... self... // Self is substituted by C, which is the defining type at compile time
}
I think it would be surprising if self produced the name of the enclosing static type: Self produces the dynamic type, and we’d want to preserve consistency if it were named self.
As a compile-time substitution, it could be used in any and all of the examples in your bullet list as a literal text replacement..
Quick rundown:
struct A {
...self... // self is substituted by A
}
class B {
...self... // Self is substituted by B
}
class C {
... self... // Self is substituted by C, which is the defining type at compile time
}
I'm stepping away from endorsing or pushing this forward. If you want to pick this up and run with it, it's yours.
I may do this if there is enough support from others. Lets see what the response is in this thread. Thanks for starting it.
···
On May 10, 2016, at 9:50 AM, Erica Sadun <erica@ericasadun.com> wrote:
-- E
On May 10, 2016, at 8:34 AM, Matthew Johnson <matthew@anandabits.com <mailto:matthew@anandabits.com>> wrote:
Can you clarify where would self would be allowed?
* property declarations
* method signatures
* method and computed property bodies
* all of the above
I would like to see this and allowed in all of the above.
We should also consider allowing this in protocol requirements. It would not covary like Self does for return types, instead being fixed by the class that declares conformance.
Sent from my iPad
On May 10, 2016, at 8:15 AM, Erica Sadun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
To focus SE-0068 and narrow its scope, I removed the `#Self` part of the proposal. This offered compile-time substitution of the defining type for a related self literal:
A further static identifier, self expands to static type of the code it appears within, completing the ways code may want to refer to the type it is declared in.
self expands to the static type of the code it is declared within. In value types, this is always the same as Self. In reference types, it refers to the declaring type. self will offer a literal textual replacement just like #file, etc.
At Chris's suggestion, I'm starting a new SE thread to see whether there remains any interest for including self in the language. I'm personally happy with the SE-0068 outcome but I didn't want to undercut anyone like Timothy Wood who had originally spoken up for its inclusion.
As a compile-time substitution, it could be used in any and all of the examples in your bullet list as a literal text replacement..
Quick rundown:
struct A {
...self... // self is substituted by A
}
class B {
...self... // Self is substituted by B
}
class C {
... self... // Self is substituted by C, which is the defining type at compile time
}
I think it would be surprising if self produced the name of the enclosing static type: Self produces the dynamic type, and we’d want to preserve consistency if it were named self.
That's a fair critique. Having a more distinct name will make it clear that the behavior is completely unrelated to Self.
How about #Type or #StaticType?
···
Sent from my iPad
On May 10, 2016, at 10:56 AM, Chris Lattner <clattner@apple.com> wrote:
On May 10, 2016, at 7:50 AM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:
As a compile-time substitution, it could be used in any and all of the examples in your bullet list as a literal text replacement..
Quick rundown:
struct A {
...self... // self is substituted by A
}
class B {
...self... // Self is substituted by B
}
class C {
... self... // Self is substituted by C, which is the defining type at compile time
}
I think it would be surprising if self produced the name of the enclosing static type: Self produces the dynamic type, and we’d want to preserve consistency if it were named self.
I’m not sure I understand this comment -- if self should mean the same as Self, why would it get added? My whole point in suggesting self was that it mirrored #file and #line in that it was a compile time replacement of some static information.
It isn't at all the same. Self is covariant with the dynamic context. self, #Type, #StaticType or whatever we call it is statically determined by the lexical context.
···
Sent from my iPad
On May 10, 2016, at 11:01 AM, Timothy Wood via swift-evolution <swift-evolution@swift.org> wrote:
On May 10, 2016, at 8:56 AM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:
On May 10, 2016, at 7:50 AM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:
I think I misunderstood “textual replacement” to mean that self returns a string.
-Chris
···
On May 10, 2016, at 9:01 AM, Timothy Wood <tjw@me.com> wrote:
On May 10, 2016, at 8:56 AM, Chris Lattner via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On May 10, 2016, at 7:50 AM, Erica Sadun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
As a compile-time substitution, it could be used in any and all of the examples in your bullet list as a literal text replacement..
Quick rundown:
struct A {
...self... // self is substituted by A
}
class B {
...self... // Self is substituted by B
}
class C {
... self... // Self is substituted by C, which is the defining type at compile time
}
I think it would be surprising if self produced the name of the enclosing static type: Self produces the dynamic type, and we’d want to preserve consistency if it were named self.
I’m not sure I understand this comment -- if self should mean the same as Self, why would it get added? My whole point in suggesting self was that it mirrored #file and #line in that it was a compile time replacement of some static information.
class C: A {
func a() -> Self { return self }
func b(c: C) {} // b(c: self) ?
}
protocol A2 {
var a: Self {get}
}
final class C2 : A2 {
var a: C2 { return C2() } // self { return self() } ?
}
···
On 10.05.2016 17:50, Erica Sadun via swift-evolution wrote:
As a compile-time substitution, it could be used in any and all of the
examples in your bullet list as a literal text replacement..
Quick rundown:
struct A {
...self... // self is substituted by A
}
class B {
...self... // Self is substituted by B
}
class C {
... self... // Self is substituted by C, which is the defining type at
compile time
}
I'm stepping away from endorsing or pushing this forward. If you want to
pick this up and run with it, it's yours.
-- E
On May 10, 2016, at 8:34 AM, Matthew Johnson <matthew@anandabits.com >> <mailto:matthew@anandabits.com>> wrote:
Can you clarify where would self would be allowed?
* property declarations
* method signatures
* method and computed property bodies
* all of the above
I would like to see this and allowed in all of the above.
We should also consider allowing this in protocol requirements. It would
not covary like Self does for return types, instead being fixed by the
class that declares conformance.
Sent from my iPad
On May 10, 2016, at 8:15 AM, Erica Sadun via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
To focus SE-0068 and narrow its scope, I removed the `#Self` part of the
proposal. This offered compile-time substitution of the defining type
for a related self literal:
A further static identifier, |#Self| expands to static type of the
code it appears within, completing the ways code may want to refer
to the type it is declared in.
*
>#Self| expands to the static type of the code it is declared
within. In value types, this is always the same as |Self|. In
reference types, it refers to the declaring type. |#Self| will
offer a literal textual replacement just like |#file|, etc.
At Chris's suggestion, I'm starting a new SE thread to see whether there
remains any interest for including self in the language. I'm personally
happy with the SE-0068 outcome but I didn't want to undercut anyone like
Timothy Wood who had originally spoken up for its inclusion.
On May 10, 2016, at 9:03 AM, Matthew Johnson via swift-evolution <swift-evolution@swift.org> wrote:
Sent from my iPad
On May 10, 2016, at 10:56 AM, Chris Lattner <clattner@apple.com> wrote:
On May 10, 2016, at 7:50 AM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:
As a compile-time substitution, it could be used in any and all of the examples in your bullet list as a literal text replacement..
Quick rundown:
struct A {
...self... // self is substituted by A
}
class B {
...self... // Self is substituted by B
}
class C {
... self... // Self is substituted by C, which is the defining type at compile time
}
I think it would be surprising if self produced the name of the enclosing static type: Self produces the dynamic type, and we’d want to preserve consistency if it were named self.
That's a fair critique. Having a more distinct name will make it clear that the behavior is completely unrelated to Self.
Yes. That is what the # distinguishes, in my original suggesting for the previous proposal. Using a different term altogether introduces more ambiguity by raising questions about what other ways the two things differ. With `#Self`, I read that naturally as the compile-time (“#”) version of the thing being compiled (“Self”).
-tim
···
On May 10, 2016, at 9:05 AM, Matthew Johnson <matthew@anandabits.com> wrote:
It isn't at all the same. Self is covariant with the dynamic context. self, #Type, #StaticType or whatever we call it is statically determined by the lexical context.
Self and self are different for non-final classes. In protocol requirements Self would covary and self would be fixed by the class that provides conformance. The distinction is pretty subtle and is
class C: A {
func a() -> Self { return self }
func b(c: C) {} // b(c: self) ?
}
C is non-final so we must be careful. C and self both refer to the same thing. Self covaries and would thus refer to the dynamic type of the instance in both signatures and bodies. This means that a method returning Self must be overridden by all subclasses in order to return the correct type.
One of the advantages of allowing self in protocol requirements is that it is one way to solve a problem that has receive significant discussion on the list in the past: retroactively conforming non-final classes to protocols with factory methods that do not need to covary. There is no way to express a this kind of requirement in the language today.
protocol A2 {
var a: Self {get}
}
final class C2 : A2 {
var a: C2 { return C2() } // self { return self() } ?
}
In final classes and value types the type name itself (C2 in this example), Self, and self would all reference the same thing.
···
On May 10, 2016, at 10:34 AM, Vladimir.S via swift-evolution <swift-evolution@swift.org> wrote:
On 10.05.2016 17:50, Erica Sadun via swift-evolution wrote:
As a compile-time substitution, it could be used in any and all of the
examples in your bullet list as a literal text replacement..
Quick rundown:
struct A {
...self... // self is substituted by A
}
class B {
...self... // Self is substituted by B
}
class C {
... self... // Self is substituted by C, which is the defining type at
compile time
}
I'm stepping away from endorsing or pushing this forward. If you want to
pick this up and run with it, it's yours.
-- E
On May 10, 2016, at 8:34 AM, Matthew Johnson <matthew@anandabits.com >>> <mailto:matthew@anandabits.com>> wrote:
Can you clarify where would self would be allowed?
* property declarations
* method signatures
* method and computed property bodies
* all of the above
I would like to see this and allowed in all of the above.
We should also consider allowing this in protocol requirements. It would
not covary like Self does for return types, instead being fixed by the
class that declares conformance.
Sent from my iPad
On May 10, 2016, at 8:15 AM, Erica Sadun via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
To focus SE-0068 and narrow its scope, I removed the `#Self` part of the
proposal. This offered compile-time substitution of the defining type
for a related self literal:
A further static identifier, |#Self| expands to static type of the
code it appears within, completing the ways code may want to refer
to the type it is declared in.
*
>#Self| expands to the static type of the code it is declared
within. In value types, this is always the same as |Self|. In
reference types, it refers to the declaring type. |#Self| will
offer a literal textual replacement just like |#file|, etc.
At Chris's suggestion, I'm starting a new SE thread to see whether there
remains any interest for including self in the language. I'm personally
happy with the SE-0068 outcome but I didn't want to undercut anyone like
Timothy Wood who had originally spoken up for its inclusion.
Can you elaborate on why? This feels out of place to me in the Swift and Objective-C world.
···
Sent from my iPad
On May 10, 2016, at 11:05 AM, Austin Zheng <austinzheng@gmail.com> wrote:
/bikeshed
Austin
On May 10, 2016, at 9:03 AM, Matthew Johnson via swift-evolution <swift-evolution@swift.org> wrote:
Sent from my iPad
On May 10, 2016, at 10:56 AM, Chris Lattner <clattner@apple.com> wrote:
On May 10, 2016, at 7:50 AM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:
As a compile-time substitution, it could be used in any and all of the examples in your bullet list as a literal text replacement..
Quick rundown:
struct A {
...self... // self is substituted by A
}
class B {
...self... // Self is substituted by B
}
class C {
... self... // Self is substituted by C, which is the defining type at compile time
}
I think it would be surprising if self produced the name of the enclosing static type: Self produces the dynamic type, and we’d want to preserve consistency if it were named self.
That's a fair critique. Having a more distinct name will make it clear that the behavior is completely unrelated to Self.
It isn't at all the same. Self is covariant with the dynamic context. self, #Type, #StaticType or whatever we call it is statically determined by the lexical context.
Yes. That is what the # distinguishes, in my original suggesting for the previous proposal. Using a different term altogether introduces more ambiguity by raising questions about what other ways the two things differ. With `#Self`, I read that naturally as the compile-time (“#”) version of the thing being compiled (“Self”).
Yep, understood. It's perfectly clear to me but I understand why Chris is concerned about it having potential to confuse people. It is a pretty subtle difference especially since Self and self are the same in some contexts. In any case, I would be content to live with any name that wins out.
···
Sent from my iPad
On May 10, 2016, at 11:12 AM, Timothy Wood <tjw@me.com> wrote:
On May 10, 2016, at 9:05 AM, Matthew Johnson <matthew@anandabits.com> wrote:
Either of those would make more sense to me than using # as a distinguisher for dynamic vs static. This isn’t what we use # for.
-Chris
···
On May 10, 2016, at 9:03 AM, Matthew Johnson <matthew@anandabits.com> wrote:
class C {
... self... // Self is substituted by C, which is the defining type at compile time
}
I think it would be surprising if self produced the name of the enclosing static type: Self produces the dynamic type, and we’d want to preserve consistency if it were named self.
That's a fair critique. Having a more distinct name will make it clear that the behavior is completely unrelated to Self.
Self and self are different for non-final classes. In protocol
requirements Self would covary and self would be fixed by the class
that provides conformance. The distinction is pretty subtle and is
Will both variants coexist? I'd prefer compiler to be strict in this case and allows only self in b() method, as this is more correct and explicit declaration, i.e. func b(c: Self) in protocol A really means func b(c: self). No?
class C: A { func a() -> Self { return self } func b(c: C) {} // b(c: self) ? }
C is non-final so we must be careful. C and self both refer to the
same thing. Self covaries and would thus refer to the dynamic type of
the instance in both signatures and bodies. This means that a method
returning Self must be overridden by all subclasses in order to return
the correct type.
Yes, I believe it is all clear with a() method. This is why I placed the commend with self for `b` method only
One of the advantages of allowing self in protocol requirements is that
it is one way to solve a problem that has receive significant discussion
on the list in the past: retroactively conforming non-final classes to
protocols with factory methods that do not need to covary. There is no
way to express a this kind of requirement in the language today.
Could you please illustrate this in a couple lines of code? Just to fully understand.
protocol A2 { var a: Self {get} }
final class C2 : A2 { var a: C2 { return C2() } // self { return self() } ? }
In final classes and value types the type name itself (C2 in this
example), Self, and self would all reference the same thing.
Exactly in my example, you can't use `Self` keyword in class:
final class C2 : A2 {
var a: Self { return Self() } // error
}
but I expect to be able to have:
final class C2 : A2 {
var a: self { return self() }
}
···
On 10.05.2016 18:47, Matthew Johnson wrote:
On May 10, 2016, at 10:34 AM, Vladimir.S via swift-evolution >> <swift-evolution@swift.org> wrote:
On 10.05.2016 17:50, Erica Sadun via swift-evolution wrote:
As a compile-time substitution, it could be used in any and all of
the examples in your bullet list as a literal text replacement..
Quick rundown:
struct A { ...self... // self is substituted by A }
class B { ...self... // Self is substituted by B }
class C { ... self... // Self is substituted by C, which is the
defining type at compile time }
I'm stepping away from endorsing or pushing this forward. If you
want to pick this up and run with it, it's yours.
-- E
On May 10, 2016, at 8:34 AM, Matthew Johnson >>>> <matthew@anandabits.com <mailto:matthew@anandabits.com>> wrote:
Can you clarify where would self would be allowed?
* property declarations * method signatures * method and computed
property bodies * all of the above
I would like to see this and allowed in all of the above.
We should also consider allowing this in protocol requirements.
It would not covary like Self does for return types, instead being
fixed by the class that declares conformance.
Sent from my iPad
On May 10, 2016, at 8:15 AM, Erica Sadun via swift-evolution >>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> >>>> wrote:
To focus SE-0068 and narrow its scope, I removed the `#Self`
part of the proposal. This offered compile-time substitution of
the defining type for a related self literal:
A further static identifier, |#Self| expands to static type of
the code it appears within, completing the ways code may want to
refer to the type it is declared in.
*
>#Self| expands to the static type of the code it is declared
within. In value types, this is always the same as |Self|. In
reference types, it refers to the declaring type. |#Self| will
offer a literal textual replacement just like |#file|, etc.
At Chris's suggestion, I'm starting a new SE thread to see
whether there remains any interest for including self in the
language. I'm personally happy with the SE-0068 outcome but I
didn't want to undercut anyone like Timothy Wood who had
originally spoken up for its inclusion.