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

[Howard Lovatt]

@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/5e4e0a3b/attachment.html>