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

[Howard Lovatt]

Hi Jordan,

Yes implementing `==` will patch the example I gave, but it isn't a general
solution. Consider this variation:

class Static: Equatable {
    class One: Static {}
    static let one = One()
    class Two: Static {}
    static let two = Two()
    func e() -> String {
        switch self {
        case Static.one:
            return "one"
        case Static.two :
            return "two"
        default:
            return "unknown"
        }
    }
}
func ==(lhs: Static, rhs: Static) -> Bool {
    return lhs === rhs
}

Still needs the type qualifiers :(.

  -- Howard.

On 17 February 2016 at 11:31, Jordan Rose <jordan_rose at apple.com> wrote:

> 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> wrote:
>
>>
>> On Feb 15, 2016, at 8:58, Erica Sadun via swift-evolution <
>> 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
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160217/6d60b7ad/attachment.html>