Re: [swift-evolution] [Pitch] Adding a Self type name shortcut for static member access

> Am 27.04.2016 um 22:00 schrieb Erica Sadun : > > >> On Apr 27, 2016, at 1:51 PM, Thorsten Seitz via swift-evolution >> > wrote: >> >> So, you are probably right that Self does not make sense in value types. >

Re: [swift-evolution] [Pitch] Adding a Self type name shortcut for static member access

> On Apr 27, 2016, at 1:51 PM, Thorsten Seitz via swift-evolution > wrote: > > So, you are probably right that Self does not make sense in value types. I courteously disagree for the reasons stated in the proposal: * Self introduces consistency across types * It’s

Re: [swift-evolution] [Pitch] Adding a Self type name shortcut for static member access

> Am 23.04.2016 um 06:56 schrieb Brent Royal-Gordon : > >>> Having said all this, now that we have `#Self`, I'm wondering if we still >>> want `Self` in value types. The two are *exactly* equivalent in value types >>> as far as I can tell, and `Self` in classes implies

Re: [swift-evolution] [Pitch] Adding a Self type name shortcut for static member access

>> Having said all this, now that we have `#Self`, I'm wondering if we still >> want `Self` in value types. The two are *exactly* equivalent in value types >> as far as I can tell, and `Self` in classes implies dynamic behavior which >> is not supported by value types. The use of `Self` in

Re: [swift-evolution] [Pitch] Adding a Self type name shortcut for static member access

on Sat Apr 09 2016, Chris Lattner wrote: > On Apr 4, 2016, at 7:13 PM, Joe Groff via swift-evolution > wrote: >>> On Apr 4, 2016, at 11:17 AM, Erica Sadun wrote: On Apr 4, 2016, at 12:13 PM, Joe Groff

Re: [swift-evolution] [Pitch] Adding a Self type name shortcut for static member access

On Apr 4, 2016, at 7:13 PM, Joe Groff via swift-evolution wrote: >> On Apr 4, 2016, at 11:17 AM, Erica Sadun wrote: >>> On Apr 4, 2016, at 12:13 PM, Joe Groff wrote: >>> On Apr 4, 2016, at 11:00 AM, Erica Sadun via

Re: [swift-evolution] [Pitch] Adding a Self type name shortcut for static member access

> On Apr 6, 2016, at 11:09 PM, David Hart wrote: > > There's something I find very confusing with this proposal, and it's how Self > is already used in protocol definitions to represent the STATIC type of the > type that conforms to the protocol. I think people will be

Re: [swift-evolution] [Pitch] Adding a Self type name shortcut for static member access

> On Apr 7, 2016, at 6:17 AM, Brent Royal-Gordon via swift-evolution > wrote: > Having said all this, now that we have `#Self`, I'm wondering if we still > want `Self` in value types. The two are *exactly* equivalent in value types > as far as I can tell, and `Self`

Re: [swift-evolution] [Pitch] Adding a Self type name shortcut for static member access

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

Re: [swift-evolution] [Pitch] Adding a Self type name shortcut for static member access

> As I understand it, the proposal is that `Self` can be used as an alias to > `self.dynamicType`, which is an object in the sense of entity in Swift but > not an instance of a class or struct. You don't understand it correctly. Currently, `Self` in a class definition means "whatever subclass

Re: [swift-evolution] [Pitch] Adding a Self type name shortcut for static member access

There's something I find very confusing with this proposal, and it's how Self is already used in protocol definitions to represent the STATIC type of the type that conforms to the protocol. I think people will be potentially very confused by how Self represents different types in different

Re: [swift-evolution] [Pitch] Adding a Self type name shortcut for static member access

> On Apr 5, 2016, at 4:04 PM, Joe Groff wrote: > > >> On Apr 5, 2016, at 3:02 PM, Erica Sadun wrote: >> >> As the discussion seems to be quieting down, I've tried to summarize the >> on-list discussion and distill it into a preliminary proposal draft.

Re: [swift-evolution] [Pitch] Adding a Self type name shortcut for static member access

on Wed Apr 06 2016, Brent Royal-Gordon wrote: >> Alternatively, why is it ‘dynamicType’ and not just ‘type’? > > I suspect this has something to do with the 27 methods in various OS X > frameworks named `type`. (To be fair, 17 of those are in WebKit's DOM > classes.)

Re: [swift-evolution] [Pitch] Adding a Self type name shortcut for static member access

on Wed Apr 06 2016, Jeremy Pereira wrote: > I think I would be -1 on this. > > The proposal is that there be two names, Self and self that refer to > different objects but are differentiated only by the capitalisation of > the first letter and these could be mixed in

Re: [swift-evolution] [Pitch] Adding a Self type name shortcut for static member access

on Wed Apr 06 2016, "Bernd Ohr (jazzbox) via swift-evolution" wrote: > I am using a typealias for this: > > struct MyStruct { > private typealias _Self = MyStruct > > static func staticMethod() { print("staticMethod") } > > func instanceMethod() { >

Re: [swift-evolution] [Pitch] Adding a Self type name shortcut for static member access

> Alternatively, why is it ‘dynamicType’ and not just ‘type’? I suspect this has something to do with the 27 methods in various OS X frameworks named `type`. (To be fair, 17 of those are in WebKit's DOM classes.) What I'm less sure about is why it's not a free function instead. Other than the

Re: [swift-evolution] [Pitch] Adding a Self type name shortcut for static member access

I think I would be -1 on this. The proposal is that there be two names, Self and self that refer to different objects but are differentiated only by the capitalisation of the first letter and these could be mixed in the same context. I think this would make code that uses both harder to read.

Re: [swift-evolution] [Pitch] Adding a Self type name shortcut for static member access

+1 for Self and the proposal. Pozdrawiam – Regards, Adrian Kashivskyy > Wiadomość napisana przez Bernd Ohr (jazzbox) via swift-evolution > w dniu 06.04.2016, o godz. 09:11: > > I am using a typealias for this: > > struct MyStruct { >private typealias _Self =

Re: [swift-evolution] [Pitch] Adding a Self type name shortcut for static member access

I am using a typealias for this: struct MyStruct { private typealias _Self = MyStruct static func staticMethod() { print("staticMethod") } func instanceMethod() { _Self.staticMethod() } } > > On Apr 5, 2016, at 4:17 PM, Timothy > >

Re: [swift-evolution] [Pitch] Adding a Self type name shortcut for static member access

> On Apr 5, 2016, at 3:21 PM, Erica Sadun wrote: > > Please check to ensure that the changes I just made match your expectations: > > https://gist.github.com/erica/c60c7d51809889f3dfd47cdb482d6227 > That

Re: [swift-evolution] [Pitch] Adding a Self type name shortcut for static member access

> On Apr 5, 2016, at 4:17 PM, Timothy Wood wrote: > > >> On Apr 5, 2016, at 3:04 PM, Joe Groff via swift-evolution >> > wrote: >> >> What you're describing should be spelled `Self`, IMO. I think Tim intended >>

Re: [swift-evolution] [Pitch] Adding a Self type name shortcut for static member access

> On Apr 5, 2016, at 3:04 PM, Joe Groff via swift-evolution > wrote: > > What you're describing should be spelled `Self`, IMO. I think Tim intended > `#Self` to mean the *static* type the code is declared inside (which is the > same as Self unless you're in a

Re: [swift-evolution] [Pitch] Adding a Self type name shortcut for static member access

Updating. Gist here: https://gist.github.com/erica/c60c7d51809889f3dfd47cdb482d6227 -- E > On Apr 5, 2016, at 4:04 PM, Joe Groff wrote: > >> >> On Apr 5, 2016, at 3:02 PM, Erica Sadun wrote: >> >> As the discussion seems to be quieting down, I've

Re: [swift-evolution] [Pitch] Adding a Self type name shortcut for static member access

> On Apr 5, 2016, at 3:02 PM, Erica Sadun wrote: > > As the discussion seems to be quieting down, I've tried to summarize the > on-list discussion and distill it into a preliminary proposal draft. Please > let me know if this covers what you think it should or if I've

Re: [swift-evolution] [Pitch] Adding a Self type name shortcut for static member access

As the discussion seems to be quieting down, I've tried to summarize the on-list discussion and distill it into a preliminary proposal draft. Please let me know if this covers what you think it should or if I've entirely missed the mark. (It wouldn't be the first time.) Regards, -- Erica

Re: [swift-evolution] [Pitch] Adding a Self type name shortcut for static member access

> On Apr 5, 2016, at 11:41 AM, Russ Bishop wrote: > > But if you don’t want subclasses to override it then why are you making it > internal/public in the first place? I'm wan’t talking about overriding it… In my earlier posts I was talking about subclasses being able to

Re: [swift-evolution] [Pitch] Adding a Self type name shortcut for static member access

> On Apr 5, 2016, at 7:34 AM, Timothy Wood via swift-evolution > wrote: > > >> On Apr 4, 2016, at 7:13 PM, Joe Groff via swift-evolution >> > wrote: >>> Would using another word or symbol fix that

Re: [swift-evolution] [Pitch] Adding a Self type name shortcut for static member access

I too would like a #Self. In my (subjective, biased) experience, sufficiently descriptive type names are usually long enough to make working with static members painfully onerous. If there's still the risk of confusion (compile-time type versus runtime type), maybe #Self can be limited to

Re: [swift-evolution] [Pitch] Adding a Self type name shortcut for static member access

> On Apr 5, 2016, at 10:06 AM, Joe Groff via swift-evolution > wrote: > >> >> On Apr 5, 2016, at 7:34 AM, Timothy Wood via swift-evolution >> wrote: >> >> >>> On Apr 4, 2016, at 7:13 PM, Joe Groff via swift-evolution >>>

Re: [swift-evolution] [Pitch] Adding a Self type name shortcut for static member access

> On Apr 5, 2016, at 7:34 AM, Timothy Wood via swift-evolution > wrote: > > >> On Apr 4, 2016, at 7:13 PM, Joe Groff via swift-evolution >> wrote: >>> Would using another word or symbol fix that problem? >> >> My preference would be for

Re: [swift-evolution] [Pitch] Adding a Self type name shortcut for static member access

> My preference would be for there to be only one Self, and have it always be > the dynamic type of 'self'. Some people disagree, but I don't think it's all > that onerous to have to write ClassName.foo if that's really what you > specifically mean. +1. There's just no way we want to explain

Re: [swift-evolution] [Pitch] Adding a Self type name shortcut for static member access

On Apr 4, 2016, at 8:13 PM, Joe Groff wrote: > On Apr 4, 2016, at 11:17 AM, Erica Sadun wrote: >> On Apr 4, 2016, at 12:13 PM, Joe Groff wrote: >>> On Apr 4, 2016, at 11:00 AM, Erica Sadun via swift-evolution >>>

Re: [swift-evolution] [Pitch] Adding a Self type name shortcut for static member access

> On Apr 4, 2016, at 11:17 AM, Erica Sadun wrote: > > >> On Apr 4, 2016, at 12:13 PM, Joe Groff wrote: >> >>> >>> On Apr 4, 2016, at 11:00 AM, Erica Sadun via swift-evolution >>> wrote: >>> >>> Are there reasons that

Re: [swift-evolution] [Pitch] Adding a Self type name shortcut for static member access

> Are there reasons that prevent using `Self` as a synonym for an instance's > type name? > > Consider: > > struct MyStruct { > static func foo() { print("foo") } > func bar() { > MyStruct.foo() // works > self.dynamicType.foo() // works > Self.foo() // error >

Re: [swift-evolution] [Pitch] Adding a Self type name shortcut for static member access

> On Apr 4, 2016, at 1:39 PM, Howard Lovatt wrote: > > If the `.StaticMember` (no type name) notation discussed already at least > twice, in the context of expanding the `.EnumCase` syntax, was accepted, this > would eleviate the problem. I was thinking about the

Re: [swift-evolution] [Pitch] Adding a Self type name shortcut for static member access

If the `.StaticMember` (no type name) notation discussed already at least twice, in the context of expanding the `.EnumCase` syntax, was accepted, this would eleviate the problem. On Tuesday, 5 April 2016, Timothy Wood via swift-evolution < swift-evolution@swift.org> wrote: > > On Apr 4, 2016,

Re: [swift-evolution] [Pitch] Adding a Self type name shortcut for static member access

> On Apr 4, 2016, at 11:00 AM, Erica Sadun via swift-evolution > wrote: > > Are there reasons that prevent using `Self` as a synonym for an instance's > type name? > [...] > > I'd like to see `Self.staticMember` introduced as a synonym for >

Re: [swift-evolution] [Pitch] Adding a Self type name shortcut for static member access

> On Apr 4, 2016, at 12:13 PM, Joe Groff wrote: > >> >> On Apr 4, 2016, at 11:00 AM, Erica Sadun via swift-evolution >> wrote: >> >> Are there reasons that prevent using `Self` as a synonym for an instance's >> type name? >> >> Consider: >> >>

Re: [swift-evolution] [Pitch] Adding a Self type name shortcut for static member access

> On Apr 4, 2016, at 11:00 AM, Erica Sadun via swift-evolution > wrote: > > Are there reasons that prevent using `Self` as a synonym for an instance's > type name? > > Consider: > > struct MyStruct { > static func foo() { print("foo") } > func bar() { >

Re: [swift-evolution] [Pitch] Adding a Self type name shortcut for static member access

I’ve wondered this as well. Using “self.dynamicType” is noisy and somewhat esoteric, and using “MyStruct.foo” is bad the moment you want to rename “MyStruct”. l8r Sean > On Apr 4, 2016, at 1:00 PM, Erica Sadun via swift-evolution > wrote: > > Are there reasons

[swift-evolution] [Pitch] Adding a Self type name shortcut for static member access

Are there reasons that prevent using `Self` as a synonym for an instance's type name? Consider: struct MyStruct { static func foo() { print("foo") } func bar() { MyStruct.foo() // works self.dynamicType.foo() // works Self.foo() // error } } Obviously, you