[RFC] #Self


(Erica Sadun) #1

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.

-- E


(Matthew Johnson) #2

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.

-- E

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Patrick Smith) #3

Is there an example of a before / after? Thanks.

···

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.

-- E

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Erica Sadun) #4

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.

-- E

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution


(Chris Lattner) #5

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
}


(Timothy Wood) #6

The initial three cases I’d considered were:

1) Textual replacement inside struct/enum/class. This avoids longer boilerplate repetition, making code easier to read and refactor.

2) Default method arguments, like #file and #line, evaluated at the call site, not implementation site. So:

  --- A.swift ---

  class A {
    static func register(_ cls: A.Type = #Self.self)
  }

  --- B.swift ---

  class B : A {
    static func foo() {
      register()
    }
  }

  In this case, the `cls` argument would resolve to B.self (with the ‘.self’ bits possibly not being needed in Swift 3).

3) Adoption points in protocols.

  protocol P {
    static func implementingClass() -> P.Type {
      return #Self.self
    }
  }

  class A : P {}
  class B : A {}

  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.

-- E

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution


(Timothy Wood) #7

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.


(Matthew Johnson) #8

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.

-- E

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution


(Matthew Johnson) #9

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:

-Chris


(Matthew Johnson) #10

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:

-tim

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Chris Lattner) #11

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.


(Vladimir) #12

What about #Self in protocols? I.e. is it proposed to have #Self in protocols, where conformance will require a substitution by real type name?

protocol A {
     func a() -> Self
     func b(c: Self) // b(c: #Self) ?
}

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.

-- E

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Austin Zheng) #13

I'm partial to #This or #ThisType.

/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.

How about #Type or #StaticType?

-Chris

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution


(Timothy Wood) #14

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.


(Matthew Johnson) #15

What about #Self in protocols? I.e. is it proposed to have #Self in protocols, where conformance will require a substitution by real type name?

protocol A {
   func a() -> Self
   func b(c: Self) // b(c: #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

protocol A {
   func a() -> Self
   func b(c: #Self)
}

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.

-- E

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Matthew Johnson) #16

I'm partial to #This or #ThisType.

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.

How about #Type or #StaticType?

-Chris

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Matthew Johnson) #17

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:

-tim


(Chris Lattner) #18

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.

How about #Type or #StaticType?


(Vladimir) #19

Thank you for answers, just to clarify:

What about #Self in protocols? I.e. is it proposed to have #Self in
protocols, where conformance will require a substitution by real type
name?

protocol A { func a() -> Self func b(c: Self) // b(c: #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

protocol A { func a() -> Self func b(c: #Self) }

Yes, Self and #Self sometimes is not the same, and sometimes is the same.
Here I asked about b() method. No questions regarding a() method.

So, after #Self will be introduced, this definition will be correct:

protocol A {
  func a() -> Self
  func b(c: #Self)
}

and be exactly the same as

protocol A {
  func a() -> Self
  func b(c: Self)
}

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.

-- E

_______________________________________________ swift-evolution
mailing list swift-evolution@swift.org
<mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________ swift-evolution
mailing list swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________ swift-evolution
mailing list swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Vladimir) #20

I think we should be explicit, so my vote is #StaticSelf. And I'd prefer we have DynamicSelf instead of current `Self`

···

On 10.05.2016 19:03, Matthew Johnson via swift-evolution wrote:

How about #Type or #StaticType?