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@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@swift.org> wrote:
On Feb 15, 2016, at 8:58, Erica Sadun via swift-evolution < >> swift-evolution@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution