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

[Howard Lovatt]

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 at swift.org> wrote:

> Matthew Johnson via swift-evolution
> <swift-evolution at swift.org <javascript:;>> wrote:
> >
> >> On Apr 1, 2016, at 4:07 PM, Dave Abrahams via swift-evolution
> >> <swift-evolution at swift.org <javascript:;>> wrote:
> >>
> >> Douglas Gregor via swift-evolution
> >> <swift-evolution at 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 at swift.org <javascript:;>
> >> https://lists.swift.org/mailman/listinfo/swift-evolution
> >
> >
> >
>
>
>
> --
> -Dave
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <javascript:;>
> https://lists.swift.org/mailman/listinfo/swift-evolution
>


-- 
-- Howard.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160403/5f7ec92d/attachment.html>