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:
Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at
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
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:
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
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:
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
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.
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:
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
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:
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:
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
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")
}
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:
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
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:
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
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:
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:
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
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.
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:
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
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:
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:
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
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.
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
>>> <GitHub - apple/swift-evolution: This maintains proposals for changes and user-visible enhancements to the Swift Programming Language.
>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.
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.
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.
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.