[Review] SE-0068: Expanding Swift Self to class members and value types


(Chris Lattner) #1

Hello Swift community,

The review of "SE-0068: Expanding Swift Self to class members and value types" begins now and runs through April 25. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0068-universal-self.md

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

  https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  * What is your evaluation of the proposal?
  * Is the problem being addressed significant enough to warrant a change to Swift?
  * Does this proposal fit well with the feel and direction of Swift?
  * If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at

  https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager


(Dave Abrahams) #2

Caveat: somewhat scattered response, probably after insufficient
review; apply salt liberally.

This looks like a good idea overall to me, but I think it may leave
important uses for Self on the floor. For example, I still want to
write this:

  struct SomeType {
    func f(x: Self) {}
  }

Does the proposal make that work in some way that I've overlooked?

IMO it's a shame that you can't take a protocol body, dump it into your
type's body, and fill in the implementations to satisfy a conformance
without finding all the instances of “Self” and replacing them with your
type's name, and it would be sad if this proposal didn't address that
somehow. In general, I'm concerned that we may be making “Self” mean
two very different things in different contexts: IIUC one is a type
that's fully-resolved at compile time, and the other one is a value that
holds a metatype. If there were less of a wall between the two
uses/contexts, that would make the proposal more palatable to me.

···

on Wed Apr 20 2016, Chris Lattner <swift-evolution@swift.org> wrote:

Hello Swift community,

The review of "SE-0068: Expanding Swift Self to class members and value types"
begins now and runs through April 25. The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0068-universal-self.md

--
Dave


(Charles Srstka) #3

* What is your evaluation of the proposal?

Mixed. I definitely think we need the functionality, but I think naming it “Self” may be confusing, since it means “self” and “Self” will mean two distinct things, despite varying only in the case of the first letter.

* Is the problem being addressed significant enough to warrant a change to Swift?

Definitely. As the proposal says, MyExtremelyLargeTypeName.staticMember is very unwieldy and awkward, and also fragile in case the type's name is changed.

* Does this proposal fit well with the feel and direction of Swift?

I feel that if given a name other than Self, it will be. As proposed, there is a potential for confusion between “self” and “Self”.

* If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

Objective-C has [[self class] classMethod] but lacks type checking on it. This is an improvement.

* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Read through the whole thing.

Charles

···

On Apr 20, 2016, at 12:16 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

Hello Swift community,

The review of "SE-0068: Expanding Swift Self to class members and value types" begins now and runs through April 25. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0068-universal-self.md

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

  https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  * What is your evaluation of the proposal?
  * Is the problem being addressed significant enough to warrant a change to Swift?
  * Does this proposal fit well with the feel and direction of Swift?
  * If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at

  https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager

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


(Tino) #4

+1
It's not breaking anything, it's a useful feature, and I think it adds consistency:
I already encountered situations where I tried to use "Self" in contexts where it is not available now.

Tino


(Timothy Wood) #5

  * What is your evaluation of the proposal?

+1 — yes, please!

  * Is the problem being addressed significant enough to warrant a change to Swift?

Yes, this is a big cleanup of mental overhead when accessing class/static properties and functions that are related to the instance. This avoids the need to confirm, each time you read it, that the name of the receiver is the same as the name of the containing class/struct/whatever, as well as avoiding subtle bugs when refactoring code.

  * Does this proposal fit well with the feel and direction of Swift?

Yes, this helps avoid bugs, and shows clear intent. The name of `Self` shows the clear relationship between that and `self` where `dynamicType` does not.

  * If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

No, but I’ve certainly been annoyed by its lack in other languages…

  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

A close reading of the proposal and associated threads.

-tim

···

On Apr 20, 2016, at 10:16 AM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:


(Ergin Bilgin) #6

At first it looked like a good idea to me but then I realized it may lead
to a lot of confusion especially for beginners. self.dynamicType looks much
more self explanatory and actually little bit easier to read since I do not
have to pay attention to capitalization.

···

On 20 April 2016 at 20:16, Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote:

Hello Swift community,

The review of "SE-0068: Expanding Swift Self to class members and value
types" begins now and runs through April 25. The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0068-universal-self.md

Reviews are an important part of the Swift evolution process. All reviews
should be sent to the swift-evolution mailing list at

https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the
review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review
through constructive criticism and, eventually, determine the direction of
Swift. When writing your review, here are some questions you might want to
answer in your review:

* What is your evaluation of the proposal?
* Is the problem being addressed significant enough to warrant a change to
Swift?
* Does this proposal fit well with the feel and direction of Swift?
* If you have you used other languages or libraries with a similar
feature, how do you feel that this proposal compares to those?
* How much effort did you put into your review? A glance, a quick reading,
or an in-depth study?

More information about the Swift evolution process is available at

https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager

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


(Vladimir) #7

I almost totally support this proposal.

The only thing is worrying me in confusion between the currently defined type(where method is declared) and dynamic type of class at runtime.

Plus, note that we have currently "self" as *type* object inside class/static methods.

I.e. let's we have such code :

···

--------------------
class A {
     class func classX() { print("in classX : class A") }

     class func classY() { self.classX() } // Self.classX() is proposed. if we'll have A.classX() here - we'll have another behavior

     func y() { self.dynamicType.classY() } // Self.classY() is proposed
}

class B: A {
    override class func classX() { print("in classX : class B") }
}

var a = A()
var b = B()

a.y() >> in classX : class A
b.y() >> in classX : class B
--------------------

Currently, in classY() "self.classX()" is also confusing. "self" is not "A" here, but "dynamicType". So it is ok to have "Self.classX()" at this place. (the same (probably less) level of confusion i.e. "is Self is A or dynamicType")

But in y() the "self.dynamicType" is much more explicit and clear than "Self". Yes, if we'll know that Swift *is* dynamicType - we'll use it correctly, I believe. And if I have to choose : to implement this proposal or leave "dynamicType" and "self" in static/class methods - I choose to have proposed "Self" in Swift 3.0.

Probably, it will be better to name this "Self" in some other way..
Don't have good variants.. like "DynamicSelf" ?

And, I believe we need some kind of "Self" to address currently defined class like in this case(I support, we should be able to just copy-paste the func from protocol to our class definition, typing the name of our class in implementation is making our codebase more fragile if class is renamed ):

protocol AProtocol {
     func assignFrom(a: Self) // now. confusing if this is Self = "dynamicType" ?
     // func assignFrom(a: ThisType) // suggested
}

class A : AProtocol {
     var x = 10

     func assignFrom(a: A) { // now . no that "Self" is placeholder for "A"
     // func assignFrom(a: ThisType) { // suggested

         self.x = a.x
     }
}

Probably #ThisType, as this is compilator's business to replace this with actually defined class name. Or #Type.. Or even #Self. This can be discussed.

Opinions?

Btw, can't understand how self and Self could be confused - in Swift it is so natural to have the instance name as just lowercased name of class :
let page = Page(withTitle: "Page Title")
so, we have self, the instance of some type, and the type of that instance is Self.

On 20.04.2016 20:16, Chris Lattner via swift-evolution wrote:

Hello Swift community,

The review of "SE-0068: Expanding Swift Self to class members and value
types" begins now and runs through April 25. The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0068-universal-self.md

Reviews are an important part of the Swift evolution process. All reviews
should be sent to the swift-evolution mailing list at

https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review
manager.

What goes into a review?

The goal of the review process is to improve the proposal under review
through constructive criticism and, eventually, determine the direction of
Swift. When writing your review, here are some questions you might want to
answer in your review:

* What is your evaluation of the proposal?
* Is the problem being addressed significant enough to warrant a change to
Swift?
* Does this proposal fit well with the feel and direction of Swift?
* If you have you used other languages or libraries with a similar feature,
how do you feel that this proposal compares to those?
* How much effort did you put into your review? A glance, a quick reading,
or an in-depth study?

More information about the Swift evolution process is available at

https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager

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


(Sebastian Hagedorn) #8

  * What is your evaluation of the proposal?

Generally +1, but disagree on the naming.

  * Is the problem being addressed significant enough to warrant a change to Swift?

Yes.

  * Does this proposal fit well with the feel and direction of Swift?

Generally, yes. However, I don’t think “Self” is very readable or easily understandable. “dynamicType” on the other hand can hardly be misunderstood. With Self, one first has to know/understand that there is a difference between static and dynamic types, and then know/look up which of these types is returned. With dynamicType, this is clear from the beginning. If you don’t know what a dynamic type is, you will stumble over the word and there’s a much higher chance you’d do the research. I don’t think we should value upper/lowercase consistency higher than readability of the code (including what it actually does).

  * If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

ObjC, but I don’t think this compares well, as type lookup at runtime is only available for classes.

  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Read the proposal and all replies that have come in since.


(Erica Sadun) #9

RELATED DISCUSSIONS

* Design Team feedback <http://article.gmane.org/gmane.comp.lang.swift.evolution/15009> on SE-0068
* [Pitch] Adding a Self type name shortcut for static member access <http://thread.gmane.org/gmane.comp.lang.swift.evolution/13708>
* [Pitch] Rename `x.dynamicType` to `x.Self` <http://thread.gmane.org/gmane.comp.lang.swift.evolution/14445>
* Making `.self` after `Type` optional <http://thread.gmane.org/gmane.comp.lang.swift.evolution/9059>
* Remove the Need for 'self' to Access 'dynamicType' <http://thread.gmane.org/gmane.comp.lang.swift.evolution/14173>

SHOULD .self BE REMOVED FROM TYPES

Design team notes say:

We have a proposal to remove .self on types. One reason .self exists is to avoid the mistake of writing let x = Int — the compiler will give you a weird type error later on in code if the value of x is what we today call Int.self but you meant to call the Int() initializer. Creating a metatype is not a common operation, so doing it explicitly is a good thing.

Coming back to this proposal, if we removed .self why would we want to add .Self?

Background:
From Joe Groff: "`.self` is also a bit of load-bearing duct-tape that currently supports some other parsing aspects of Swift's syntax."
Jordan Rose adds, "Swift's type-checking engine is strong enough to merit not needing the redundant `.self` safety check."

I personally like distinguishing `Type.self` from raw `Type` use for the reasons stated. This feature affirmatively prevents the use of `Typename` when `Typename()` is meant. In terms of this proposal, can this and should this be retained in the language but renamed from `self`? That would update the quiz to:

Self.<runcible> // T.Type
self.Self // T.Type
Self.Self // T.Type.Type
self.<runcible> // == self
Which reduces at least some of the confusion. The actual runcible name could be bikeshedded.

IS `Self` THE RIGHT NAME? / SHOULD `dynamicType` require `self`

I like `Self`. It is an existing keyword. It matches the approach used in protocols where `Self` is a placeholder for the type that conforms to that protocol. Under SE-0068, it refers to the dynamic type of the current instance. If it has to be a choice of one or the other, I'd prefer renaming `.self` and retaining `Self`. If `Self` is not the right name, I'd recommend either the `dynamictype` keyword and dropping the `self` prefix requirement or using a freestanding `dynamicType()` call.

We have one keyword left in the language, dynamicType, which is camel cased. This proposal renames it to Self instead.

Why don’t we turn this into a standard library function? It’s not something you need so often that the member access is very valuable. Putting it in the standard library as dynamicType(_:slight_smile: does still allow for that function to be implemented using compiler magic.

Another approach would be to introduce a new dynamictype keyword that doesn’t need to be accessed as a member of self, and keep Self the way it is. Self should work in structs as a type alias.

Another perspective is that .dynamicType is just an implicitly synthesized property on all type.

Subjectively, having dynamicType as a member feels weird.

If retained as a keyword, I believe it should be lowercased to `dynamictype`. This leaves two remaining outliers (`willSet` and `didSet`). If it is re-introduced as a stdlib function, it should be `dynamicType()`.

···

On Apr 20, 2016, at 11:16 AM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

Hello Swift community,

The review of "SE-0068: Expanding Swift Self to class members and value types" begins now and runs through April 25. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0068-universal-self.md

------

ORIGINAL DESIGN TEAM FEEDBACK
SE-0068: Expanding Swift Self to class members and value types <file:///Users/alexmartini/DevPubs%20Git%20Repositories/Swift%20Language%20Review/_build/html/LR_MeetingNotes/2016-04-20.html#se-0068-expanding-swift-self-to-class-members-and-value-types>
https://github.com/apple/swift-evolution/blob/master/proposals/0068-universal-self.md
We have one keyword left in the language, dynamicType, which is camel cased. This proposal renames it to Self instead.

In a static function today, self.dynamicType will give you a metatype but the non-member Self will not. The most useful reason to reference it is to call an initializer. It makes accessing the metatype weirder. It’s not Self.Type; that’s a type — you have to spell it Self.type.

Quiz time! What do each of the permutations mean?

Self.self
self.Self
Self.Self
self.self
The number of capital letters gives you the level of meta-ness. This is very subtle, which is probably not a good thing.

Another approach would be to introduce a new dynamictype keyword that doesn’t need to be accessed as a member of self, and keep Self the way it is. Self should work in structs as a type alias.

Why don’t we turn this into a standard library function? It’s not something you need so often that the member access is very valuable. Putting it in the standard library as dynamicType(_:slight_smile: does still allow for that function to be implemented using compiler magic.

func dynamicType<T>(_: T) -> T.Type { }
We have a proposal to remove .self on types. One reason .self exists is to avoid the mistake of writing let x = Int — the compiler will give you a weird type error later on in code if the value of x is what we today call Int.self but you meant to call the Int() initializer. Creating a metatype is not a common operation, so doing it explicitly is a good thing.

It’s weird that you can use the metatype directly to construct something or to do member access, but you can’t access it as a bare value.

Coming back to this proposal, if we removed .self why would we want to add .Self?

If you have a variable whose value is a metatype, you also keep its name in lower case. So Self makes a little less sense from that aspect too.

Another perspective is that .dynamicType is just an implicitly synthesized property on all type.

We do have other keywords that follow the dot on types, Int.Type and Fooable.Protocol, so this isn’t the only thing. Those things are magic nested types.

Subjectively, having dynamicType as a member feels weird.

If .self goes away, the four-self example above is simplified, and .Self doesn’t make sense anymore. There’s also the difference that .Self would be a runtime thing.


(Jeremy Pereira) #10

  * What is your evaluation of the proposal?

-1

Addressing the issues cited in the proposal:

  • dynamicType remains an exception to Swift's lowercased keywords rule. This change eliminates a special case that's out of step with Swift's new standards.

Except for the fact that `dynamicType` cannot be used with implicit self, it has always felt more like a property to me than a keyword and the capitalisation is therefore not out of place. The camel case does not jar for me in the same way that writing `someInstance.Self` would.

NB the keyword `Self` would also violate the all-lowercase keyword rule.

  • Self is shorter and clearer in its intent. It mirrors self, which refers to the current instance.

It is undeniably shorter, but it is not clearer in intent. `self.dynamicType` clearly and explicitly tells us we are referring to the runtime type of the instance. `Self` does not. Furthermore, it overloads the word with two subtly different meanings depending on context.

  • It provides an easier way to access static members. As type names grow large, readability suffers. MyExtremelyLargeTypeName.staticMember is unwieldy to type and read.

I reject the assertion that readability suffers with large type names. `NSApplicationDelegate` is much more readable than `NSAppDlgt` for example.

Furthermore, this proposal does not address the length of `MyExtremelyLargeTypeName.someMember()` since that might not be the same method as `Self.someMember()` If you explicitly want the `someMember()` defined by `MyExtremelyLargeTypeName` you still have to spell it out in case it is a class function and the dynamic type is a subclass.

  • Code using hardwired type names is less portable than code that automatically knows its type.

And how does `self.dynamicType` fail here?

  • Renaming a type means updating any TypeName references in code.

This is the same point as the previous one.

  • Using self.dynamicType fights against Swift's goals of concision and clarity in that it is both noisy and esoteric.

I disagree. `self.dynamicType` is a clear and concise description of the object it represents.

Another observation: the proposal omits the “Impact own Existing Code” section. I think this would be a breaking change for a lot of existing code.

Also, I’m disappointed that no alternatives seem to have been documented.

  * Is the problem being addressed significant enough to warrant a change to Swift?

No.

  * Does this proposal fit well with the feel and direction of Swift?

No, unless the direction of Swift is to go for maximum terseness at the expense of clarity.

  * If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

In Objective-C you can write [self class] to get the runtime class of an object. I think that is a better choice of name. In Swift the analogue would probably be `self.type`. Was this considered?

  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

I’ve been following the thread.

···

On 20 Apr 2016, at 18:16, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:


(Brent Royal-Gordon) #11

  https://github.com/apple/swift-evolution/blob/master/proposals/0068-universal-self.md

I'm not totally clear what's being proposed here.

Is this valid?

  class Foo {
    static func bar() { … }
    func baz(other: Foo) {
      Self.bar()
    }
  }

Is this valid?

  struct Foo { // note: not class
    static func bar() { … }
    func baz(other: Foo) {
      Self.bar()
    }
  }

Is this valid?

  class Foo {
    static func bar() { … }
    func baz(other: Foo) {
      other.Self.bar() // note: not self
    }
  }

Is this valid?

  struct Foo { // note: not class
    static func bar() { … }
    func baz(other: Foo) {
      other.Self.bar() // note: not self
    }
  }

Can a class have a variable (inside a method) of type Self? A return value? A parameter? A property?

Can a value type have a variable (inside a method) of type Self? A return value? A parameter? A property?

···

--
Brent Royal-Gordon
Architechies


(Erica Sadun) #12

It kind of did address this until late last night. I was worried that proposing #Self and Self at the
same time would be divisive. The point of #Self would be a compile-time replacement of the name
of the defining type, vs the run-time evaluation of Self. Trying to propose two things at once
seemed like a difficult sell.

If there's sufficient support for doing so, I can add it back in as a revision to the proposal if
the core team requests it.

-- E

···

On Apr 20, 2016, at 12:37 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:

on Wed Apr 20 2016, Chris Lattner <swift-evolution@swift.org> wrote:

Hello Swift community,

The review of "SE-0068: Expanding Swift Self to class members and value types"
begins now and runs through April 25. The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0068-universal-self.md

Caveat: somewhat scattered response, probably after insufficient
review; apply salt liberally.

This looks like a good idea overall to me, but I think it may leave
important uses for Self on the floor. For example, I still want to
write this:

struct SomeType {
   func f(x: Self) {}
}

Does the proposal make that work in some way that I've overlooked?

IMO it's a shame that you can't take a protocol body, dump it into your
type's body, and fill in the implementations to satisfy a conformance
without finding all the instances of “Self” and replacing them with your
type's name, and it would be sad if this proposal didn't address that
somehow. In general, I'm concerned that we may be making “Self” mean
two very different things in different contexts: IIUC one is a type
that's fully-resolved at compile time, and the other one is a value that
holds a metatype. If there were less of a wall between the two
uses/contexts, that would make the proposal more palatable to me.


(Vladimir) #13

I feel like we should separate all these self/Self/dynamicType explicity.

For example :

DynamicSelf - where we use "self.dynamicType" in instance methods and "self" in class/static methods

#ThisType (or #Type or #Self or ?) - where we need a replacement for "the exactly type name where this method is declared"

I.e. you'll have
   struct SomeType {
     func f(x: #ThisType) {}
   }

protocol SomeProtocol {
   func f(x: #ThisType)
}

class SomeClass: SomeProtocol {
   func f(x: #ThisType) { }
}

but

class SomeClass {
   class func classF() { DynamicSelf.someOtherClassF() }

   func f() {
     DynamicSelf.someStaticMethod()
   }
}

···

On 20.04.2016 21:37, Dave Abrahams via swift-evolution wrote:

on Wed Apr 20 2016, Chris Lattner <swift-evolution@swift.org> wrote:

Hello Swift community,

The review of "SE-0068: Expanding Swift Self to class members and value types"
begins now and runs through April 25. The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0068-universal-self.md

Caveat: somewhat scattered response, probably after insufficient
review; apply salt liberally.

This looks like a good idea overall to me, but I think it may leave
important uses for Self on the floor. For example, I still want to
write this:

  struct SomeType {
    func f(x: Self) {}
  }

Does the proposal make that work in some way that I've overlooked?

IMO it's a shame that you can't take a protocol body, dump it into your
type's body, and fill in the implementations to satisfy a conformance
without finding all the instances of “Self” and replacing them with your
type's name, and it would be sad if this proposal didn't address that
somehow. In general, I'm concerned that we may be making “Self” mean
two very different things in different contexts: IIUC one is a type
that's fully-resolved at compile time, and the other one is a value that
holds a metatype. If there were less of a wall between the two
uses/contexts, that would make the proposal more palatable to me.


(Erica Sadun) #14

  https://github.com/apple/swift-evolution/blob/master/proposals/0068-universal-self.md

I'm not totally clear what's being proposed here.

Is this valid?

  class Foo {
    static func bar() { … }
    func baz(other: Foo) {
      Self.bar()
    }
  }

This is valid. Foo.bar().

Is this valid?

  struct Foo { // note: not class
    static func bar() { … }
    func baz(other: Foo) {
      Self.bar()
    }
  }

This is valid. Foo.bar()

Is this valid?

  class Foo {
    static func bar() { … }
    func baz(other: Foo) {
      other.Self.bar() // note: not self
    }
  }

This is valid. Foo.bar(). All instances of the class share the static bar() member.

Is this valid?

  struct Foo { // note: not class
    static func bar() { … }
    func baz(other: Foo) {
      other.Self.bar() // note: not self
    }
  }

This is should be valid although it currently errors with `dynamicType` (error: type 'Foo' has no member 'bar').

You missed subclassing, although being static members, methods are final and cannot be overridden. But if class Boo : Foo calls Self.bar() and Foo implements the static member, it's called from the Boo instance and uses the Foo implementation.

Can a class have a variable (inside a method) of type Self? A return value? A parameter? A property?

I think it should, however that technically may need to be of type #Self (per the original draft) instead of Self and have it expanded to the defining type at compile time.

Can a value type have a variable (inside a method) of type Self? A return value? A parameter? A property?

Ditto.

-- E

···

On Apr 24, 2016, at 7:57 PM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:

--
Brent Royal-Gordon
Architechies

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


(Chris Lattner) #15

The core team discussed this briefly today, and has several concerns with the direction of the proposal. Alex will be sending out notes in a bit.

-Chris

···

On Apr 20, 2016, at 1:27 PM, Erica Sadun <erica@ericasadun.com> wrote:

It kind of did address this until late last night. I was worried that proposing #Self and Self at the
same time would be divisive. The point of #Self would be a compile-time replacement of the name
of the defining type, vs the run-time evaluation of Self. Trying to propose two things at once
seemed like a difficult sell.

If there's sufficient support for doing so, I can add it back in as a revision to the proposal if
the core team requests it.


(Vladimir) #16

I believe we just have to separate these concepts explicity : i.e. "dynamicType" and "Self"(as replacement for type name in protocol)

Yes, seems like we need Self and #Self to separate these. Or we should select a better names, if we have better suggestions.

···

On 20.04.2016 23:27, Erica Sadun via swift-evolution wrote:

On Apr 20, 2016, at 12:37 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:

on Wed Apr 20 2016, Chris Lattner <swift-evolution@swift.org> wrote:

Hello Swift community,

The review of "SE-0068: Expanding Swift Self to class members and value types"
begins now and runs through April 25. The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0068-universal-self.md

Caveat: somewhat scattered response, probably after insufficient
review; apply salt liberally.

This looks like a good idea overall to me, but I think it may leave
important uses for Self on the floor. For example, I still want to
write this:

struct SomeType {
   func f(x: Self) {}
}

Does the proposal make that work in some way that I've overlooked?

IMO it's a shame that you can't take a protocol body, dump it into your
type's body, and fill in the implementations to satisfy a conformance
without finding all the instances of “Self” and replacing them with your
type's name, and it would be sad if this proposal didn't address that
somehow. In general, I'm concerned that we may be making “Self” mean
two very different things in different contexts: IIUC one is a type
that's fully-resolved at compile time, and the other one is a value that
holds a metatype. If there were less of a wall between the two
uses/contexts, that would make the proposal more palatable to me.

It kind of did address this until late last night. I was worried that proposing #Self and Self at the
same time would be divisive. The point of #Self would be a compile-time replacement of the name
of the defining type, vs the run-time evaluation of Self. Trying to propose two things at once
seemed like a difficult sell.

If there's sufficient support for doing so, I can add it back in as a revision to the proposal if
the core team requests it.

-- E

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