[swift-evolution] [Discussion] Enum Leading Dot Prefixes

[Patrick Gili]

+1, as it adds consistency to the language.

> On Feb 11, 2016, at 10:00 PM, Erica Sadun via swift-evolution <swift-evolution at swift.org> wrote:
> 
> https://gist.github.com/erica/e0b8a3a22ab716a19db4 <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 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/20160213/1021ca05/attachment-0001.html>