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


(Douglas Gregor) #1

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
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
Thank you,

Doug Gregor

Review Manager


(Brent Royal-Gordon) #2

https://github.com/apple/swift-evolution/blob/master/proposals/0036-enum-dot.md

  • What is your evaluation of the proposal?

In favor. This is a simple, clean win—there's not much else to say about it.

  • Is the problem being addressed significant enough to warrant a change to Swift?

Yes. This kind of inconsistency encourages subtle confusion.

  • Does this proposal fit well with the feel and direction of Swift?

Yes.

  • If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

Can't think of anything relevant.

  • How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Quick read of this latest draft, but I participated in the discussion as well.

···

--
Brent Royal-Gordon
Architechies


(Matthew Johnson) #3

What is your evaluation of the proposal?

+1. The current behavior is surprising in a somewhat confusing way.

Is the problem being addressed significant enough to warrant a change to Swift?

Yes

Does this proposal fit well with the feel and direction of Swift?

Yes

If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

I haven’t used a language with leading dot shorthand so I don’t have a point of comparison.

How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Followed the thread on the mailing list and read the proposal.


(Patrick Gili) #4

What is your evaluation of the proposal?

Anything that increases consistency is good.

Is the problem being addressed significant enough to warrant a change to Swift?

Yes.

Does this proposal fit well with the feel and direction of Swift?

Yes.

If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

n/a

How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Quick read.


(Sebastian Hagedorn) #5

What is your evaluation of the proposal?

+1

Is the problem being addressed significant enough to warrant a change to Swift?

Yes, it is pretty confusing, especialyl for beginners. I can’t see any benefit in the discarded syntax (without dot).

Does this proposal fit well with the feel and direction of Swift?

Yes.

If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

not applicable

How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Read the proposal and followed the mailing list discussion briefly. I’ve also noticed the issue in my code.

···

On 01 Apr 2016, at 05:41, Douglas Gregor <dgregor@apple.com> 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
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
Thank you,

Doug Gregor

Review Manager

_______________________________________________
swift-evolution-announce mailing list
swift-evolution-announce@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution-announce


(Dave Abrahams) #6

Douglas Gregor via swift-evolution

···

<swift-evolution@swift.org> 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.

--
-Dave


(Charles Srstka) #7

The correctness of this proposal seems somewhat self-evident.

+1.

Charles

···

On Mar 31, 2016, at 10:41 PM, Douglas Gregor via swift-evolution <swift-evolution@swift.org> 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
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
Thank you,

Doug Gregor

Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Ilya Belenkiy) #8

+1

···

On Thu, Mar 31, 2016 at 11:41 PM Douglas Gregor via swift-evolution < swift-evolution@swift.org> 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

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

Thank you,

Doug Gregor

Review Manager
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


#9

Wondering if this fit more in the lexer/in-house coding style bucket.
For the supplied example of "badness", 'case heads', one can also write 'case Coins.heads' and with the latest Erica's pitch, one day 'case Self.heads'; are these also going to be disallowed?
I have always seen, the leading dot as an opt-in shortcut that the parser allowed us to use when the context/type can be inferred, and as such the usage of leading dot should probably be left to the user.

The problem I see from the example, is not the inconsistency with 'case heads' vs 'case .tails' (as coding style) but that you can define in the enum:

static let bluenose:Coin = .tails

And then use it in:
var coin:Coin = .bluenose
if coin == .bluenose { print("tails") }

But not in:
switch coin {
    case .bluenose: print("tails")
    default: print("heads")
}

Dany

···

Le 31 mars 2016 à 23:41, Douglas Gregor via swift-evolution <swift-evolution@swift.org> a écrit :
:
https://github.com/apple/swift-evolution/blob/master/proposals/0036-enum-dot.md


(Taras Zakharko) #10

How would this work with OptionSetType? It also uses leading dot prefixes for initialisers, but implementations are usually structs. If I understand correctly, leading dot can be used in any case where the type can be inferred by the compiler. Changing the rules for enums seems strange to me.

Best,

Taras

···

On 01 Apr 2016, at 05:41, Douglas Gregor via swift-evolution <swift-evolution@swift.org> 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
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
Thank you,

Doug Gregor

Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(E. Maloney) #11

What is your evaluation of the proposal?

+1.

In addition to bringing greater consistency, requiring the leading dot will make it easier to grep one's codebase for enum case values.

Is the problem being addressed significant enough to warrant a change to Swift?

Yes.

Does this proposal fit well with the feel and direction of Swift?

Yes.

If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

n/a

How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Followed the mailing list discussion and read the proposal.


(Matthew Johnson) #12

Douglas Gregor via swift-evolution

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.

···

On Apr 1, 2016, at 4:07 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:
<swift-evolution@swift.org> wrote:

--
-Dave

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Howard Lovatt) #13

+1 Same as Matthew Johnson said

···

On Friday, 1 April 2016, Matthew Johnson via swift-evolution < swift-evolution@swift.org> wrote:

   - What is your evaluation of the proposal?

+1. The current behavior is surprising in a somewhat confusing way.

   - Is the problem being addressed significant enough to warrant a
   change to Swift?

Yes

   - Does this proposal fit well with the feel and direction of Swift?

Yes

   - If you have used other languages or libraries with a similar
   feature, how do you feel that this proposal compares to those?

I haven’t used a language with leading dot shorthand so I don’t have a
point of comparison.

   - How much effort did you put into your review? A glance, a quick
   reading, or an in-depth study?

Followed the thread on the mailing list and read the proposal.

--
-- Howard.


(David Hart) #14

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

On Apr 1, 2016, at 4:07 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Douglas Gregor via swift-evolution
<swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution


(Dave Abrahams) #15

Matthew Johnson via swift-evolution

Douglas Gregor via swift-evolution

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.

···

<swift-evolution@swift.org> wrote:

On Apr 1, 2016, at 4:07 PM, Dave Abrahams via swift-evolution >> <swift-evolution@swift.org> wrote:
<swift-evolution@swift.org> wrote:

--
-Dave

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
-Dave


(Matthew Johnson) #16

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

···

Sent from my iPad

On Apr 2, 2016, at 9:04 AM, David Hart <david@hartbit.com> wrote:

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

On Apr 1, 2016, at 4:07 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:

Douglas Gregor via swift-evolution
<swift-evolution@swift.org> 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
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Howard Lovatt) #17

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.


(Erica Sadun) #18

Can you ping me off-list or in another thread and explain what the issues are?

Thank you,

-- Erica

···

On Apr 2, 2016, at 11:13 AM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:

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.


(Brent Royal-Gordon) #19

As as been pointed out in the past, why not make a leading dot mean static (including enum). This would be nice and consistent.

And it would break the common pattern of doing things like:

  string.compare(otherString, options: [.caseInsensitive, .numeric])

Leading dot can only mean one thing; if it means "static member on the type of Self", it cannot mean "static member on the inferred type of the expression".

Now, what might be nice is if you could say `Self.someCase` or `Type.someCase` to access a static member without retyping the type name. Alas, we are not so lucky as that.

···

--
Brent Royal-Gordon
Architechies


(Howard Lovatt) #20

I meant any static member, inferred self or inferred other. So your example
would be unchanged.

···

On Sunday, 3 April 2016, Brent Royal-Gordon <brent@architechies.com> wrote:

> As as been pointed out in the past, why not make a leading dot mean
static (including enum). This would be nice and consistent.

And it would break the common pattern of doing things like:

        string.compare(otherString, options: [.caseInsensitive, .numeric])

Leading dot can only mean one thing; if it means "static member on the
type of Self", it cannot mean "static member on the inferred type of the
expression".

Now, what might be nice is if you could say `Self.someCase` or
`Type.someCase` to access a static member without retyping the type name.
Alas, we are not so lucky as that.

--
Brent Royal-Gordon
Architechies

--
-- Howard.