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 < [email protected]> wrote: > > On Apr 4, 2016, at 11:00 AM, Erica Sadun via swift-evolution < > [email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>> 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 > `TypeName.staticMember`. > > > I would love to see a way to get the type of the "enclosing thing at > compile time”. In my particular case, I’m using the type as a generic > parameter to tag a created resource with something like: > > class Client: PropertyOwner { > let intProperty = Client.property(“name”, Int(0)) > } > > > where PropertyOwner has a static property<Owner, DataType>(...) > > With `Self` meaning the static version of the thing being compiled, I > could at least write: > > class Client: PropertyOwner { > let intProperty = Self.property(“name”, Int(0)) > } > > > which would have the benefit of being harder to mess up due to > copy-pasting between different PropertyOwner implementors. > > I would love to be able to omit the `Self.` entirely, but instances can’t > call functions on themselves at init time, and instances don’t see static > funcs, so that probably won’t fly =) > > The particular spelling of ‘static self` doesn’t matter too much to me, so > if `Self` needs to be the runtime type of the executing class then maybe > `StaticSelf` could be added. > > -tim > > -- -- Howard.
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
