As as been pointed out in the past, why not make a leading dot mean static (including enum). This would be nice and consistent.
On Sunday, 3 April 2016, Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote: > Matthew Johnson via swift-evolution > <swift-evolution@swift.org <javascript:;>> wrote: > > > >> On Apr 1, 2016, at 4:07 PM, Dave Abrahams via swift-evolution > >> <swift-evolution@swift.org <javascript:;>> wrote: > >> > >> Douglas Gregor via swift-evolution > >> <swift-evolution@swift.org <javascript:;>> 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. > > I believe I misread the proposal and you are right. > > I do have reservations about leading dot syntax that are highlighted by > this sentence in the proposal: > > A leading dot has become a conventional shorthand for "enumeration case" > across the language. > > That isn't in fact what it means, and if we have to play into that > misperception I think it indicates a bigger problem. But we can handle that > outside of this review. > > >> > >> -- > >> -Dave > >> > >> _______________________________________________ > >> swift-evolution mailing list > >> swift-evolution@swift.org <javascript:;> > >> https://lists.swift.org/mailman/listinfo/swift-evolution > > > > > > > > > > -- > -Dave > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org <javascript:;> > https://lists.swift.org/mailman/listinfo/swift-evolution > -- -- Howard.
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution