[swift-evolution] [Discussion] Using dot prefixes to infer non-enumeration static members

Dany St-Amant dsa.mls at icloud.com
Mon Feb 15 12:25:04 CST 2016


> Le 15 févr. 2016 à 11:58, Erica Sadun via swift-evolution <swift-evolution at swift.org> a écrit :
> 
> 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.


Not sure if it’s valid concern, but the current shorthand is based on the immediate context of comparison/pattern matching. Adding shorthand here for static member reference within the class could introduce some resolution conflicts. 

enum MyEnum {
    case one
    case two
    
    static func stillOne() -> MyEnum { return one }
}

let data:MyEnum = .one
if .stillOne() == data { print("Something!") }

struct MyStruct {
    static var data:MyEnum = .one
    static func stillOne() -> Bool { return data == .one }
    
    func instanceMember() {
        if .stillOne() == MyStruct.data { print("Something") } // This currently work
    }
}

The current logic easily resolves the code inside instanceMember() as a shorthand to MyEnum,  but if we expand the shorthand as describe, will it make it too hard on the compiler.


Dany

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160215/651d481c/attachment.html>


More information about the swift-evolution mailing list