[swift-evolution] [Discussion] Using dot prefixes to infer non-enumeration static members
Erica Sadun
erica at ericasadun.com
Mon Feb 15 10:58:12 CST 2016
While discussing leading enumeration dot prefixes, Howard Lovatt asked why static properties and methods could not be inferred via a dot prefix as well. Based on Swift-Evolution conventions, here's a new thread to discuss this idea: specifically, would it be beneficial (and/or possible) to use dot prefixes to denote static member references in instance member code.
Howard wrote:
> +1 for the proposal, it is wierd to use `.` in some places and not others.
>
> On the subject of static methods and properties in general, would it be possible for `.name` to be a reference to a static and `name` a reference to an instance? EG:
>
> .name = x // static
> name = x // instance
> x = name + .name // instance + static
> r = name ... .name // instance ... static, needs space
> r = name...Type.name // Can still qualify with type name
>
Under the current system, you must explicitly name or derive a type to access static members from instance member implementations.
struct MyStruct {
static func staticMember() {}
func instanceMember() {
// name a type
MyStruct.staticMember() // works
// derive a type
self.dynamicType.staticMember() // works
// error: value of tuple type '()' has no member 'staticMember'
// does not work
.staticMember()
}
}
Using dot prefixes for static member access:
* Has precedent in enumeration members
* Would streamline Swift code
* Is visually differentiated from `self`-prefixed instance member references
What are your thoughts, both technical and philosophical, on a change like this? Thanks in advance for your feedback.
-- Erica
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160215/5eeec8b7/attachment.html>
More information about the swift-evolution
mailing list