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

[Jordan Rose]

That works just as well outside the enum:

enum Enum {
    case one
    case two
}
func e(value: Enum) -> String {
    if value == .one {
        return "one"
    } else if value == .two {
        return "two"
    }
    return "unkown"
}

Here it's looking in the contextual type provided by ==. The enum synthesizes a function along the lines of

func ==(a: Enum, b: Enum)

This doesn't work for === because you can compare identity across class types.

func ===(a: AnyObject, b: AnyObject)

Jordan


> On Feb 16, 2016, at 16:20, Howard Lovatt <howard.lovatt at gmail.com> wrote:
> 
> @Jordan,
> 
> You said "I don't think we want to change or overload that rule to also look up static members of the enclosing lexical context type (i.e. the type of 'self')." But you do already; inside an enum, e.g.:
> 
> enum Enum {
>     case one
>     case two
>     func e() -> String {
>         if self == .one {
>             return "one"
>         } else if self == .two {
>             return "two"
>         }
>         return "unkown"
>     }
> }
> Compared to inside a static:
> 
> class Static {
>     class One: Static {}
>     static let one = One()
>     class Two: Static {}
>     static let two = Two()
>     func e() -> String {
>         if self === Static.one {
>             return "one"
>         } else if self === Static.two {
>             return "two"
>         }
>         return "unknown"
>     }
> }
> Why so different? The enum version looks inside the type `Enum` to find `.one` and `.two`, but the static version doesn't look inside the type `Static` and hence you have to say `Static.one` and `Static.two` :(
> 
> 
>   -- Howard.
> 
> On 16 February 2016 at 05:40, Jordan Rose via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> 
>> On Feb 15, 2016, at 8:58, Erica Sadun via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> 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.
> 
> Dot-prefixed member expressions are currently looked up as static members of the contextual type, which lets you do things like this:
> 
> import AppKit
> let colors: [NSColor] = [.redColor(), .blueColor()]
> 
> I don't think we want to change or overload that rule to also look up static members of the enclosing lexical context type (i.e. the type of 'self').
> 
> Jordan
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> 

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