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