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

[David Hart]

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)?

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 <mailto:swift-evolution at swift.org>> wrote:
>> 
>> Douglas Gregor via swift-evolution
>> <swift-evolution at swift.org <mailto: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 <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 <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <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/f4dc30e8/attachment.html>