[swift-evolution] [Review] SE-0036: Requiring Leading Dot Prefixes for Enum Instance Member Implementations

[Matthew Johnson]

Sent from my iPad

> On Apr 2, 2016, at 9:04 AM, David Hart <david at hartbit.com> wrote:
> 
> Hello Matthew,
> 
> If the goal is to make rules for accessing static members and enum cases more consistent, why can’t static members be accessed from inside the type cope with a dot prefix (sorry for the grim example)?

Actually they can as long as they return a value of the type.

struct Person {
    static let Bob: Person = Person(name: "Bob")
    let name: String
}

Let bob: Person = .Bob


> 
> struct Person {
>     static let lifeExpectency: Int = 80
>     let age: Int
>     var lifeRatio: Double { return Double(age) / Double(.lifeExpectency) }
> }
> 
> David.
> 
>>> On 01 Apr 2016, at 23:19, Matthew Johnson via swift-evolution <swift-evolution at swift.org> wrote:
>>> 
>>> 
>>> On Apr 1, 2016, at 4:07 PM, Dave Abrahams via swift-evolution <swift-evolution at swift.org> wrote:
>>> 
>>> Douglas Gregor via swift-evolution
>>> <swift-evolution at swift.org> wrote:
>>>> Hello Swift community,
>>>> 
>>>> The review of SE-0036 "Requiring Leading Dot Prefixes for Enum Instance
>>>> Member Implementations" begins now and runs throughApril 5, 2016. The
>>>> proposal is available here:
>>>> 
>>>> https://github.com/apple/swift-evolution/blob/master/proposals/0036-enum-dot.md
>>>> Reviews are an important part of the Swift evolution process. All reviews
>>>> should be sent to the swift-evolution mailing list at
>>>> 
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>> or, if you would like to keep your feedback private, directly to the
>>>> review manager. When replying, please try to keep the proposal link at
>>>> the top of the message:
>>>> 
>>>> Proposal link:
>>>> 
>>>> https://github.com/apple/swift-evolution/blob/master/proposals/0036-enum-dot.md
>>>> Reply text
>>>> 
>>>> Other replies
>>>> <https://github.com/apple/swift-evolution#what-goes-into-a-review-1>What
>>>> goes into a review?
>>>> 
>>>> The goal of the review process is to improve the proposal under review
>>>> through constructive criticism and, eventually, determine the direction
>>>> of Swift. When writing your review, here are some questions you might
>>>> want to answer in your review:
>>>> 
>>>> What is your evaluation of the proposal?
>>>> Is the problem being addressed significant enough to warrant a change to Swift?
>>>> Does this proposal fit well with the feel and direction of Swift?
>>>> If you have used other languages or libraries with a similar feature, how
>>>> do you feel that this proposal compares to those?
>>>> How much effort did you put into your review? A glance, a quick reading,
>>>> or an in-depth study?
>>>> More information about the Swift evolution process is available at
>>>> 
>>>> https://github.com/apple/swift-evolution/blob/master/process.md
>>>> <https://github.com/apple/swift-evolution/blob/master/process.md>
>>>> Thank you,
>>>> 
>>>> Doug Gregor
>>>> 
>>>> Review Manager
>>> 
>>> This proposal seems to me like it's failing to fix the underlying problem,
>>> which is that people don't understand the leading dot rules, and papering
>>> over the problem by making the rule less consisten, with different behavior
>>> for enums and other type-scoped (static/class) entities. It doesn't seem
>>> like a principled solution to me. 
>> 
>> This proposal doesn’t change the leading dot rules at all.  What it does is make the rules for referencing static members *more* consistent than they are now, removing the special case for enum cases.
>> 
>> "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."
>> 
>> I believe at one point in Swift’s history all static members could be referenced directly.  This proposal seems like it is cleaning up a case that was missed when that changed. 
>> 
>> 
>>> 
>>> -- 
>>> -Dave
>>> 
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> _______________________________________________
>> 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/20160402/a62b9fac/attachment.html>