[Discussion] Enum Leading Dot Prefixes


(Erica Sadun) #1

https://gist.github.com/erica/e0b8a3a22ab716a19db4

Requiring Leading Dot Prefixes for Enum Instance Member Implementations

Proposal: TBD
Author(s): Erica Sadun <http://github.com/erica>, Chris Lattner <https://github.com/lattner>
Status: TBD
Review manager: TBD
<https://gist.github.com/erica/e0b8a3a22ab716a19db4#introduction>Introduction

Enumeration cases are essentially static not instance type members. Unlike static members in structures and classes, enumeration cases can be mentioned in initializers and instance methods without referencing a fully qualified type. This makes little sense. In no other case can an instance implementation directly access a static member. This proposal introduces a rule that requires leading dots or fully qualified references (EnumType.caseMember) to provide a more consistent developer experience to clearly disambiguate static cases from instance members.

<https://gist.github.com/erica/e0b8a3a22ab716a19db4#motivation>Motivation

Swift infers the enclosing type for a case on a developer's behalf when the use is unambiguously of a single enumeration type. Inference enables you to craft switch statements like this:

switch Coin() {
case .Heads: print("Heads")
case .Tails: print("Tails")
}
A leading dot has become a conventional shorthand for "enumeration case" across the language. When used internally in enum implementations, a leading dot is not required, nor is a type name to access the static case member. The following code is legal in Swift.

enum Coin {
    case Heads, Tails
    func printMe() {
        switch self {
        case Heads: print("Heads") // no leading dot
        case .Tails: print("Tails") // leading dot
        }

        if self == Heads { // no leading dot
            print("This is a head")
        }

        if self == .Tails { // leading dot
            print("This is a tail")
        }
    }

    init() {
        let cointoss = arc4random_uniform(2) == 0
        self = cointoss ? .Heads : Tails // mix and match leading dots
    }
}
This quirk produces a language inconsistency that can confuse developers and contravenes the guiding Principle of Least Astonishment. We propose to mandate a leading dot. This will bring case mentions into lock-step with the conventions used to reference them outside of enumeration type implementations.

<https://gist.github.com/erica/e0b8a3a22ab716a19db4#detail-design>Detail Design

Under this rule, the compiler will require a leading dot for all case members. The change will not affect other static members, which require fully qualified references from instance methods and infer self from static methods.

enum Coin {
    case Heads, Tails
    static func doSomething() { print("Something") }
    static func staticFunc() { doSomething() } // does not require leading dot
    static func staticFunc2() { let foo = .Tails } // requires leading dot
    func instanceFunc() { self.dynamicType.doSomething() } // requires full qualification
    func otherFunc() { if self == .Heads ... } // requires leading dot, also initializers

    /// ...
}
<https://gist.github.com/erica/e0b8a3a22ab716a19db4#alternatives-considered>Alternatives Considered

Other than leaving the status quo, the language could force instance members to refer to cases using a fully qualified type, as with other static members.


(Brent Royal-Gordon) #2

https://gist.github.com/erica/e0b8a3a22ab716a19db4

Requiring Leading Dot Prefixes for Enum Instance Member Implementations

  • Proposal: TBD
  • Author(s): Erica Sadun, Chris Lattner
  • Status: TBD
  • Review manager: TBD

+1. I've always found this slightly bizarre.

I assume, though, that if you're writing a static member of an enum, the unprefixed form is fine?

···

--
Brent Royal-Gordon
Architechies


(Rob Mayoff) #3

Why not go the other way then and allow instance methods to refer to static
members (or class members) directly, without the type name prefix?

···

On Thu, Feb 11, 2016 at 9:00 PM, Erica Sadun via swift-evolution < swift-evolution@swift.org> wrote:

Unlike static members in structures and classes, enumeration cases can be
mentioned in initializers and instance methods without referencing a fully
qualified type.


(Dave Abrahams) #4

https://gist.github.com/erica/e0b8a3a22ab716a19db4

Requiring Leading Dot Prefixes for Enum Instance Member Implementations

Proposal: TBD
Author(s): Erica Sadun <http://github.com/erica>, Chris Lattner <https://github.com/lattner>
Status: TBD
Review manager: TBD
<https://gist.github.com/erica/e0b8a3a22ab716a19db4#introduction>Introduction

Enumeration cases are essentially static not instance type members. Unlike static members in structures and classes, enumeration cases can be mentioned in initializers and instance methods without referencing a fully qualified type. This makes little sense. In no other case can an instance implementation directly access a static member. This proposal introduces a rule that requires leading dots or fully qualified references (EnumType.caseMember) to provide a more consistent developer experience to clearly disambiguate static cases from instance members.

<https://gist.github.com/erica/e0b8a3a22ab716a19db4#motivation>Motivation

Swift infers the enclosing type for a case on a developer's behalf when the use is unambiguously of a single enumeration type. Inference enables you to craft switch statements like this:

switch Coin() {
case .Heads: print("Heads")
case .Tails: print("Tails")
}

FYI, after considering the feedback here along with other factors, the
API guidelines working group decided a few days ago to make enum cases
lowerCamelCase like other values. Sorry I failed to announce that
earlier.

···

on Thu Feb 11 2016, Erica Sadun <swift-evolution@swift.org> wrote:

A leading dot has become a conventional shorthand for "enumeration case" across the language. When used internally in enum implementations, a leading dot is not required, nor is a type name to access the static case member. The following code is legal in Swift.

enum Coin {
    case Heads, Tails
    func printMe() {
        switch self {
        case Heads: print("Heads") // no leading dot
        case .Tails: print("Tails") // leading dot
        }

        if self == Heads { // no leading dot
            print("This is a head")
        }

        if self == .Tails { // leading dot
            print("This is a tail")
        }
    }

    init() {
        let cointoss = arc4random_uniform(2) == 0
        self = cointoss ? .Heads : Tails // mix and match leading dots
    }
}
This quirk produces a language inconsistency that can confuse developers and contravenes the guiding Principle of Least Astonishment. We propose to mandate a leading dot. This will bring case mentions into lock-step with the conventions used to reference them outside of enumeration type implementations.

<https://gist.github.com/erica/e0b8a3a22ab716a19db4#detail-design>Detail Design

Under this rule, the compiler will require a leading dot for all case members. The change will not affect other static members, which require fully qualified references from instance methods and infer self from static methods.

enum Coin {
    case Heads, Tails
    static func doSomething() { print("Something") }
    static func staticFunc() { doSomething() } // does not require leading dot
    static func staticFunc2() { let foo = .Tails } // requires leading dot
    func instanceFunc() { self.dynamicType.doSomething() } // requires full qualification
    func otherFunc() { if self == .Heads ... } // requires leading dot, also initializers

    /// ...
}
<https://gist.github.com/erica/e0b8a3a22ab716a19db4#alternatives-considered>Alternatives Considered

Other than leaving the status quo, the language could force instance members to refer to cases using a fully qualified type, as with other static members.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
-Dave


(Carlos Parada) #5

Taking consistency further, should the definition also use dot prefixes? For example:

enum Coin {
    case .Heads, .Tails
    func printMe() {
        switch self {
        case .Heads: print("Heads")
        case .Tails: print("Tails")
        }
    }
}

— Carlos Parada


(Daniel Steinberg) #6

+1 for consistency reasons

···

On Feb 11, 2016, at 10:00 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:

https://gist.github.com/erica/e0b8a3a22ab716a19db4

Requiring Leading Dot Prefixes for Enum Instance Member Implementations

Proposal: TBD
Author(s): Erica Sadun <http://github.com/erica>, Chris Lattner <https://github.com/lattner>
Status: TBD
Review manager: TBD
<https://gist.github.com/erica/e0b8a3a22ab716a19db4#introduction>Introduction

Enumeration cases are essentially static not instance type members. Unlike static members in structures and classes, enumeration cases can be mentioned in initializers and instance methods without referencing a fully qualified type. This makes little sense. In no other case can an instance implementation directly access a static member. This proposal introduces a rule that requires leading dots or fully qualified references (EnumType.caseMember) to provide a more consistent developer experience to clearly disambiguate static cases from instance members.

<https://gist.github.com/erica/e0b8a3a22ab716a19db4#motivation>Motivation

Swift infers the enclosing type for a case on a developer's behalf when the use is unambiguously of a single enumeration type. Inference enables you to craft switch statements like this:

switch Coin() {
case .Heads: print("Heads")
case .Tails: print("Tails")
}
A leading dot has become a conventional shorthand for "enumeration case" across the language. When used internally in enum implementations, a leading dot is not required, nor is a type name to access the static case member. The following code is legal in Swift.

enum Coin {
    case Heads, Tails
    func printMe() {
        switch self {
        case Heads: print("Heads") // no leading dot
        case .Tails: print("Tails") // leading dot
        }

        if self == Heads { // no leading dot
            print("This is a head")
        }

        if self == .Tails { // leading dot
            print("This is a tail")
        }
    }

    init() {
        let cointoss = arc4random_uniform(2) == 0
        self = cointoss ? .Heads : Tails // mix and match leading dots
    }
}
This quirk produces a language inconsistency that can confuse developers and contravenes the guiding Principle of Least Astonishment. We propose to mandate a leading dot. This will bring case mentions into lock-step with the conventions used to reference them outside of enumeration type implementations.

<https://gist.github.com/erica/e0b8a3a22ab716a19db4#detail-design>Detail Design

Under this rule, the compiler will require a leading dot for all case members. The change will not affect other static members, which require fully qualified references from instance methods and infer self from static methods.

enum Coin {
    case Heads, Tails
    static func doSomething() { print("Something") }
    static func staticFunc() { doSomething() } // does not require leading dot
    static func staticFunc2() { let foo = .Tails } // requires leading dot
    func instanceFunc() { self.dynamicType.doSomething() } // requires full qualification
    func otherFunc() { if self == .Heads ... } // requires leading dot, also initializers

    /// ...
}
<https://gist.github.com/erica/e0b8a3a22ab716a19db4#alternatives-considered>Alternatives Considered

Other than leaving the status quo, the language could force instance members to refer to cases using a fully qualified type, as with other static members.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Patrick Gili) #7

+1, as it adds consistency to the language.

···

On Feb 11, 2016, at 10:00 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:

https://gist.github.com/erica/e0b8a3a22ab716a19db4

Requiring Leading Dot Prefixes for Enum Instance Member Implementations

Proposal: TBD
Author(s): Erica Sadun <http://github.com/erica>, Chris Lattner <https://github.com/lattner>
Status: TBD
Review manager: TBD
<https://gist.github.com/erica/e0b8a3a22ab716a19db4#introduction>Introduction

Enumeration cases are essentially static not instance type members. Unlike static members in structures and classes, enumeration cases can be mentioned in initializers and instance methods without referencing a fully qualified type. This makes little sense. In no other case can an instance implementation directly access a static member. This proposal introduces a rule that requires leading dots or fully qualified references (EnumType.caseMember) to provide a more consistent developer experience to clearly disambiguate static cases from instance members.

<https://gist.github.com/erica/e0b8a3a22ab716a19db4#motivation>Motivation

Swift infers the enclosing type for a case on a developer's behalf when the use is unambiguously of a single enumeration type. Inference enables you to craft switch statements like this:

switch Coin() {
case .Heads: print("Heads")
case .Tails: print("Tails")
}
A leading dot has become a conventional shorthand for "enumeration case" across the language. When used internally in enum implementations, a leading dot is not required, nor is a type name to access the static case member. The following code is legal in Swift.

enum Coin {
    case Heads, Tails
    func printMe() {
        switch self {
        case Heads: print("Heads") // no leading dot
        case .Tails: print("Tails") // leading dot
        }

        if self == Heads { // no leading dot
            print("This is a head")
        }

        if self == .Tails { // leading dot
            print("This is a tail")
        }
    }

    init() {
        let cointoss = arc4random_uniform(2) == 0
        self = cointoss ? .Heads : Tails // mix and match leading dots
    }
}
This quirk produces a language inconsistency that can confuse developers and contravenes the guiding Principle of Least Astonishment. We propose to mandate a leading dot. This will bring case mentions into lock-step with the conventions used to reference them outside of enumeration type implementations.

<https://gist.github.com/erica/e0b8a3a22ab716a19db4#detail-design>Detail Design

Under this rule, the compiler will require a leading dot for all case members. The change will not affect other static members, which require fully qualified references from instance methods and infer self from static methods.

enum Coin {
    case Heads, Tails
    static func doSomething() { print("Something") }
    static func staticFunc() { doSomething() } // does not require leading dot
    static func staticFunc2() { let foo = .Tails } // requires leading dot
    func instanceFunc() { self.dynamicType.doSomething() } // requires full qualification
    func otherFunc() { if self == .Heads ... } // requires leading dot, also initializers

    /// ...
}
<https://gist.github.com/erica/e0b8a3a22ab716a19db4#alternatives-considered>Alternatives Considered

Other than leaving the status quo, the language could force instance members to refer to cases using a fully qualified type, as with other static members.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Joseph Lord) #8

+1

Didn't even know it was legal. Definitely increases consistency and simplifies the language.

J

···

On Feb 12, 2016, at 3:00 AM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:

https://gist.github.com/erica/e0b8a3a22ab716a19db4

Requiring Leading Dot Prefixes for Enum Instance Member Implementations


(Erica Sadun) #9

Your modification would affect the language on a large scale rather than creating a small tweak to become less out of sync with existing behavior. Technically, you'd have to introduce name conflict resolution, among other things. And for a community that defeated "required self" only after a large scale heated debate, any change that would make the language less precise and less readable would be a hard sell.

-- E

···

On Feb 11, 2016, at 8:17 PM, Rob Mayoff via swift-evolution <swift-evolution@swift.org> wrote:

On Thu, Feb 11, 2016 at 9:00 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Unlike static members in structures and classes, enumeration cases can be mentioned in initializers and instance methods without referencing a fully qualified type.

Why not go the other way then and allow instance methods to refer to static members (or class members) directly, without the type name prefix?
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Chris Lattner) #10

As Erica says, this is a worthwhile topic to discuss, but orthogonal from the proposal. Among other things we’d have to have a way to resolve the conflict that comes up when you have both a static and instance method with the same name (this occurs a few places in ObjC APIs).

-Chris

···

On Feb 11, 2016, at 7:17 PM, Rob Mayoff via swift-evolution <swift-evolution@swift.org> wrote:

On Thu, Feb 11, 2016 at 9:00 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Unlike static members in structures and classes, enumeration cases can be mentioned in initializers and instance methods without referencing a fully qualified type.

Why not go the other way then and allow instance methods to refer to static members (or class members) directly, without the type name prefix?


(Erica Sadun) #11

In this write-up I recommend using a prefixed form there too for consistency (staticFunc2), but I'm not married to it.

-- E

···

On Feb 11, 2016, at 9:09 PM, Brent Royal-Gordon <brent@architechies.com> wrote:

https://gist.github.com/erica/e0b8a3a22ab716a19db4

Requiring Leading Dot Prefixes for Enum Instance Member Implementations

  • Proposal: TBD
  • Author(s): Erica Sadun, Chris Lattner
  • Status: TBD
  • Review manager: TBD

+1. I've always found this slightly bizarre.

I assume, though, that if you're writing a static member of an enum, the unprefixed form is fine?

--
Brent Royal-Gordon
Architechies


(David Waite) #12

Would it be worthwhile to expand this (or create another proposal) to deal with switch cases only allowing dot syntax for use with enum cases?

Luckily OptionSetType is ArrayLiteralConvertable, because "case .True” fails because .True is not an enum case. AFAICT, this is the one case where dot prefixed values and methods are different than switch cases.

-DW

struct Decision : OptionSetType {
    typealias RawValue = UInt8
    
    let rawValue:RawValue
    
    internal init(rawValue: UInt8) {
        self.rawValue = rawValue
    }
    
    static let True = Decision(rawValue: 1)
    static let False = Decision(rawValue: 2)
}

let godel:Decision = [.True, .False]

switch godel {
case [.True]:
    print ("true!")
case [.False]:
    print ("false!")
case [.True, .False]:
    print ("both true and false!")
default:
    print ("neither true nor false!")
}

···

On Feb 11, 2016, at 9:28 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

On Feb 11, 2016, at 7:17 PM, Rob Mayoff via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Thu, Feb 11, 2016 at 9:00 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Unlike static members in structures and classes, enumeration cases can be mentioned in initializers and instance methods without referencing a fully qualified type.

Why not go the other way then and allow instance methods to refer to static members (or class members) directly, without the type name prefix?

As Erica says, this is a worthwhile topic to discuss, but orthogonal from the proposal. Among other things we’d have to have a way to resolve the conflict that comes up when you have both a static and instance method with the same name (this occurs a few places in ObjC APIs).

-Chris

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Erica Sadun) #13

Are there any reasons why it makes sense to add them to the declaration? There's no other place in the language where a member is declared (vs referenced) using a dot prefix so I'd personally lean towards "no".

-- Erica

···

On Feb 11, 2016, at 11:41 PM, Carlos Parada <carlosparada@me.com> wrote:

Taking consistency further, should the definition also use dot prefixes? For example:

enum Coin {
    case .Heads, .Tails
    func printMe() {
        switch self {
        case .Heads: print("Heads")
        case .Tails: print("Tails")
        }
    }
}

— Carlos Parada


(Chris Lattner) #14

Yes, that makes sense to me.

-Chris

···

On Feb 11, 2016, at 8:09 PM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:

https://gist.github.com/erica/e0b8a3a22ab716a19db4

Requiring Leading Dot Prefixes for Enum Instance Member Implementations

  • Proposal: TBD
  • Author(s): Erica Sadun, Chris Lattner
  • Status: TBD
  • Review manager: TBD

+1. I've always found this slightly bizarre.

I assume, though, that if you're writing a static member of an enum, the unprefixed form is fine?


(Chris Lattner) #15

Taking consistency further, should the definition also use dot prefixes?

I agree with others’ comments downthread. The goal here is to make enum cases more similar to static members, since that is how they behave. Both static members and enum cases can be referred to with the leading dot syntax already, and we wouldn’t add dot to the declaration of static members.

-Chris

···

On Feb 11, 2016, at 10:41 PM, Carlos Parada via swift-evolution <swift-evolution@swift.org> wrote:

For example:

enum Coin {
    case .Heads, .Tails
    func printMe() {
        switch self {
        case .Heads: print("Heads")
        case .Tails: print("Tails")
        }
    }
}

— Carlos Parada
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(David Waite) #16

I like this, but I think it needs to handle more cases to truly promote consistency.

In static contexts, use of the case is consistent with that of a static variable or function (value directly in scope, so no dot prefix shortcut necessary).

enum Booly {
    case truth
    case falsehood
    
    static let yes = truth
    static let no = falsehood

    static func defaulted() -> Booly {
        return truth
    }

    static func workingAlternative() -> Booly {
        return yes
    }

It is however a special case in the non-static context:

extension Booly {
    func isDefault() -> Bool {
        return self == truth
    }
    
    func brokenYesVersion() -> Bool {
        // return self == yes // Error: Static member 'yes' cannot be used on instance of type 'Booly'
        return self == .yes
    }
}

And case usage is inconsistent in the body of a switch statement. In situations like an OptionSetType implementation, the compiler will complain about use of dot syntax w.r.t. not being an enumeration member.

import Foundation

let flags:CFStringCompareFlags = [.CompareAnchored]

switch flags {
// case .CompareAnchored: // Error: Enum case 'CompareAnchored' ont found in type 'CFStringCompareFlags'
case CFStringCompareFlags.CompareAnchored:
    print("Anchored")
default:
    ()
}

In the case of enumerations, it will complain about anything from the enumerated type other than the case label!

let b:Booly = .yes

// switch b {
// case yes: // Error: Use of unresolved identifier ‘yes’
// case .yes: // Error: Enum case 'yes' not found in type 'Booly'
// case Booly.yes: // Error: Enum case 'yes' not found in type 'Booly'
//}

let externalYes = Booly.truth

switch b {
case externalYes:
    print ("finally, yes!")
default:
    ()
}

IMHO, the *only* thing that the compiler should do special with case variable usage is that, when the type beings switched over is an enum and the cases of that enum are all specified as possible cases of the switch, not require the use of a default section.

(playground code copied to https://gist.github.com/dwaite/60c8dc05e498b747d0f2 )

-DW

···

On Feb 12, 2016, at 7:23 AM, Daniel Steinberg via swift-evolution <swift-evolution@swift.org> wrote:

+1 for consistency reasons

On Feb 11, 2016, at 10:00 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

https://gist.github.com/erica/e0b8a3a22ab716a19db4

Requiring Leading Dot Prefixes for Enum Instance Member Implementations

Proposal: TBD
Author(s): Erica Sadun <http://github.com/erica>, Chris Lattner <https://github.com/lattner>
Status: TBD
Review manager: TBD
<https://gist.github.com/erica/e0b8a3a22ab716a19db4#introduction>Introduction

Enumeration cases are essentially static not instance type members. Unlike static members in structures and classes, enumeration cases can be mentioned in initializers and instance methods without referencing a fully qualified type. This makes little sense. In no other case can an instance implementation directly access a static member. This proposal introduces a rule that requires leading dots or fully qualified references (EnumType.caseMember) to provide a more consistent developer experience to clearly disambiguate static cases from instance members.

<https://gist.github.com/erica/e0b8a3a22ab716a19db4#motivation>Motivation

Swift infers the enclosing type for a case on a developer's behalf when the use is unambiguously of a single enumeration type. Inference enables you to craft switch statements like this:

switch Coin() {
case .Heads: print("Heads")
case .Tails: print("Tails")
}
A leading dot has become a conventional shorthand for "enumeration case" across the language. When used internally in enum implementations, a leading dot is not required, nor is a type name to access the static case member. The following code is legal in Swift.

enum Coin {
    case Heads, Tails
    func printMe() {
        switch self {
        case Heads: print("Heads") // no leading dot
        case .Tails: print("Tails") // leading dot
        }

        if self == Heads { // no leading dot
            print("This is a head")
        }

        if self == .Tails { // leading dot
            print("This is a tail")
        }
    }

    init() {
        let cointoss = arc4random_uniform(2) == 0
        self = cointoss ? .Heads : Tails // mix and match leading dots
    }
}
This quirk produces a language inconsistency that can confuse developers and contravenes the guiding Principle of Least Astonishment. We propose to mandate a leading dot. This will bring case mentions into lock-step with the conventions used to reference them outside of enumeration type implementations.

<https://gist.github.com/erica/e0b8a3a22ab716a19db4#detail-design>Detail Design

Under this rule, the compiler will require a leading dot for all case members. The change will not affect other static members, which require fully qualified references from instance methods and infer self from static methods.

enum Coin {
    case Heads, Tails
    static func doSomething() { print("Something") }
    static func staticFunc() { doSomething() } // does not require leading dot
    static func staticFunc2() { let foo = .Tails } // requires leading dot
    func instanceFunc() { self.dynamicType.doSomething() } // requires full qualification
    func otherFunc() { if self == .Heads ... } // requires leading dot, also initializers

    /// ...
}
<https://gist.github.com/erica/e0b8a3a22ab716a19db4#alternatives-considered>Alternatives Considered

Other than leaving the status quo, the language could force instance members to refer to cases using a fully qualified type, as with other static members.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(TJ Usiyan) #17

+1 and I would not object to requiring the leading dot for enum
declarations.

···

On Fri, Feb 12, 2016 at 9:23 AM, Daniel Steinberg via swift-evolution < swift-evolution@swift.org> wrote:

+1 for consistency reasons

On Feb 11, 2016, at 10:00 PM, Erica Sadun via swift-evolution < > swift-evolution@swift.org> wrote:

https://gist.github.com/erica/e0b8a3a22ab716a19db4

Requiring Leading Dot Prefixes for Enum Instance Member Implementations

   - Proposal: TBD
   - Author(s): Erica Sadun <http://github.com/erica>, Chris Lattner
   <https://github.com/lattner>
   - Status: TBD
   - Review manager: TBD

<https://gist.github.com/erica/e0b8a3a22ab716a19db4#introduction>
Introduction

Enumeration cases are essentially static not instance type members. Unlike
static members in structures and classes, enumeration cases can be
mentioned in initializers and instance methods without referencing a fully
qualified type. This makes little sense. In no other case can an instance
implementation directly access a static member. This proposal introduces a
rule that requires leading dots or fully qualified references
(EnumType.caseMember) to provide a more consistent developer experience to
clearly disambiguate static cases from instance members.
<https://gist.github.com/erica/e0b8a3a22ab716a19db4#motivation>Motivation

Swift infers the enclosing type for a case on a developer's behalf when
the use is unambiguously of a single enumeration type. Inference enables
you to craft switch statements like this:

switch Coin() {case .Heads: print("Heads")case .Tails: print("Tails")
}

A leading dot has become a conventional shorthand for "enumeration case"
across the language. When used internally in enum implementations, a
leading dot is not required, nor is a type name to access the static case
member. The following code is legal in Swift.

enum Coin {
    case Heads, Tails
    func printMe() {
        switch self {
        case Heads: print("Heads") // no leading dot
        case .Tails: print("Tails") // leading dot
        }

        if self == Heads { // no leading dot
            print("This is a head")
        }

        if self == .Tails { // leading dot
            print("This is a tail")
        }
    }

    init() {
        let cointoss = arc4random_uniform(2) == 0
        self = cointoss ? .Heads : Tails // mix and match leading dots
    }
}

This quirk produces a language inconsistency that can confuse developers
and contravenes the guiding *Principle of Least Astonishment*. We propose
to mandate a leading dot. This will bring case mentions into lock-step with
the conventions used to reference them outside of enumeration type
implementations.
<https://gist.github.com/erica/e0b8a3a22ab716a19db4#detail-design>Detail
Design

Under this rule, the compiler will require a leading dot for all case
members. The change will not affect other static members, which require
fully qualified references from instance methods and infer self from
static methods.

enum Coin {
    case Heads, Tails
    static func doSomething() { print("Something") }
    static func staticFunc() { doSomething() } // does not require leading dot
    static func staticFunc2() { let foo = .Tails } // requires leading dot
    func instanceFunc() { self.dynamicType.doSomething() } // requires full qualification
    func otherFunc() { if self == .Heads ... } // requires leading dot, also initializers

    /// ...
}

<https://gist.github.com/erica/e0b8a3a22ab716a19db4#alternatives-considered>Alternatives
Considered
Other than leaving the status quo, the language could force instance
members to refer to cases using a fully qualified type, as with other
static members.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Sune Foldager) #18

I think wording it like that misleadingly suggests that the proposal was in any way near passing, which certainly didn’t seem to be the case.

-Sune

···

On 12 Feb 2016, at 04:26, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:

And for a community that defeated "required self" only after a large scale heated debate,


(Paul Ossenbruggen) #19

I am assuming there would be no dot in front of _?

switch value {
  case .A: “A”
  case .B: “B”
  case ._:”D” // this is not correct?
}

···

On Feb 13, 2016, at 9:18 AM, Joseph Lord via swift-evolution <swift-evolution@swift.org> wrote:

+1

Didn't even know it was legal. Definitely increases consistency and simplifies the language.

J

On Feb 12, 2016, at 3:00 AM, Erica Sadun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

https://gist.github.com/erica/e0b8a3a22ab716a19db4

Requiring Leading Dot Prefixes for Enum Instance Member Implementations

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Erica Sadun) #20

No. The wildcard match does not require a dot prefix.

-- E

···

On Feb 13, 2016, at 10:40 AM, Paul Ossenbruggen via swift-evolution <swift-evolution@swift.org> wrote:

I am assuming there would be no dot in front of _?

switch value {
  case .A: “A”
  case .B: “B”
  case ._:”D” // this is not correct?
}

On Feb 13, 2016, at 9:18 AM, Joseph Lord via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

+1

Didn't even know it was legal. Definitely increases consistency and simplifies the language.

J

On Feb 12, 2016, at 3:00 AM, Erica Sadun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

https://gist.github.com/erica/e0b8a3a22ab716a19db4

Requiring Leading Dot Prefixes for Enum Instance Member Implementations

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution