<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Apr 1, 2016, at 4:07 PM, Dave Abrahams via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Douglas Gregor via swift-evolution<br class=""><<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><blockquote type="cite" class="">Hello Swift community,<br class=""><br class="">The review of SE-0036 "Requiring Leading Dot Prefixes for Enum Instance<br class="">Member Implementations" begins now and runs throughApril 5, 2016. The<br class="">proposal is available here:<br class=""><br class=""><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0036-enum-dot.md" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0036-enum-dot.md</a><br class="">Reviews are an important part of the Swift evolution process. All reviews<br class="">should be sent to the swift-evolution mailing list at<br class=""><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""><https://lists.swift.org/mailman/listinfo/swift-evolution><br class="">or, if you would like to keep your feedback private, directly to the<br class="">review manager. When replying, please try to keep the proposal link at<br class="">the top of the message:<br class=""><br class="">Proposal link:<br class=""><br class="">https://github.com/apple/swift-evolution/blob/master/proposals/0036-enum-dot.md<br class="">Reply text<br class=""><br class="">Other replies<br class=""> <https://github.com/apple/swift-evolution#what-goes-into-a-review-1>What<br class="">goes into a review?<br class=""><br class="">The goal of the review process is to improve the proposal under review<br class="">through constructive criticism and, eventually, determine the direction<br class="">of Swift. When writing your review, here are some questions you might<br class="">want to answer in your review:<br class=""><br class="">What is your evaluation of the proposal?<br class="">Is the problem being addressed significant enough to warrant a change to Swift?<br class="">Does this proposal fit well with the feel and direction of Swift?<br class="">If you have used other languages or libraries with a similar feature, how<br class="">do you feel that this proposal compares to those?<br class="">How much effort did you put into your review? A glance, a quick reading,<br class="">or an in-depth study?<br class="">More information about the Swift evolution process is available at<br class=""><br class="">https://github.com/apple/swift-evolution/blob/master/process.md<br class=""><https://github.com/apple/swift-evolution/blob/master/process.md><br class="">Thank you,<br class=""><br class="">Doug Gregor<br class=""><br class="">Review Manager<br class=""></blockquote><br class="">This proposal seems to me like it's failing to fix the underlying problem,<br class="">which is that people don't understand the leading dot rules, and papering<br class="">over the problem by making the rule less consisten, with different behavior<br class="">for enums and other type-scoped (static/class) entities. It doesn't seem<br class="">like a principled solution to me. <br class=""></div></div></blockquote><div><br class=""></div><div>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.</div><div><br class=""></div><div>"<span style="color: rgb(51, 51, 51); font-family: 'Helvetica Neue', Helvetica, 'Segoe UI', Arial, freesans, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 16px; background-color: rgb(255, 255, 255);" class="">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. <b class="">In no other case can an instance implementation directly access a static member</b>."</span></div><div><br class=""></div>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. </div><div><br class=""></div><div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class="">-- <br class="">-Dave<br class=""><br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></div></blockquote></div><br class=""></body></html>