Sent from my iPad
> On Apr 2, 2016, at 9:04 AM, David Hart <[email protected]> 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 >>> <[email protected]> wrote: >>> >>> >>> On Apr 1, 2016, at 4:07 PM, Dave Abrahams via swift-evolution >>> <[email protected]> wrote: >>> >>> Douglas Gregor via swift-evolution >>> <[email protected]> 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 >>> [email protected] >>> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
