[Discussion] Enum Leading Dot Prefixes

The current spec has the following line:

static func staticFunc2() { let foo = .Tails } // requires leading dot

The leading dot requirement does not exist today for references to static properties and functions from a static function.

Is your proposal to:
- require a dot in front of static properties/functions in this case as well for consistency across all static things
- require a dot only in front of the case statements, to promote consistency only for use of cases within an enum
- or, do you wish to change your mind about this particular case?

Yeah, I don't like this either. You require leading dots in instance members to promote simple, clear rules…then require them in static members too, making a muddy, complicated rule there. Just treat enum cases like any other static member.

···

--
Brent Royal-Gordon
Architechies

Erica,

The current spec has the following line:

static func staticFunc2() { let foo = .Tails } // requires leading dot

The leading dot requirement does not exist today for references to static properties and functions from a static function.

Is your proposal to:
- require a dot in front of static properties/functions in this case as well for consistency across all static things
- require a dot only in front of the case statements, to promote consistency only for use of cases within an enum
- or, do you wish to change your mind about this particular case?

-DW

···

On Feb 13, 2016, at 12:31 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:

No. The wildcard match does not require a dot prefix.

-- E

On Feb 13, 2016, at 10:40 AM, Paul Ossenbruggen via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

I am assuming there would be no dot in front of _?

switch value {
  case .A: “A”
  case .B: “B”
  case ._:”D” // this is not correct?
}

On Feb 13, 2016, at 9:18 AM, Joseph Lord via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

+1

Didn't even know it was legal. Definitely increases consistency and simplifies the language.

J

On Feb 12, 2016, at 3:00 AM, Erica Sadun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

enums.md · GitHub

Requiring Leading Dot Prefixes for Enum Instance Member Implementations

_______________________________________________
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

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

This was the one place I went back and forth a few times: include it for consistency in referencing enum cases *everywhere* or leave it as is to match static behavior. I can argue it either way.

-- E

···

On Feb 13, 2016, at 1:39 PM, Brent Royal-Gordon <brent@architechies.com> wrote:

The current spec has the following line:

static func staticFunc2() { let foo = .Tails } // requires leading dot

The leading dot requirement does not exist today for references to static properties and functions from a static function.

Is your proposal to:
- require a dot in front of static properties/functions in this case as well for consistency across all static things
- require a dot only in front of the case statements, to promote consistency only for use of cases within an enum
- or, do you wish to change your mind about this particular case?

Yeah, I don't like this either. You require leading dots in instance members to promote simple, clear rules…then require them in static members too, making a muddy, complicated rule there. Just treat enum cases like any other static member.

--
Brent Royal-Gordon
Architechies

Erica,

The current spec has the following line:

static func staticFunc2() { let foo = .Tails } // requires leading dot

The leading dot requirement does not exist today for references to static properties and functions from a static function.

After focusing on this line and on the error we get back when trying it now in playground, I no longer see the reported inconsistent as such, but just as a clash of two permissible syntax, which if changed as proposed will just swap an inconsistency for another one.

For those wondering, the reported error is: type of expression is ambiguous without more context

The shorthand syntax is to be used when the compiler, and the programmer knows what the type is. In the above example, why should the compile infer that variable foo is of type Coin. It would make more sense for that particular function to be:

static func staticFunc2() { let foo = Coin.Tails }
static func staticFunc2() { let foo:Coin = .Tails }

And be consistent with (both at a global scope or as static inside the enum):

let firstCoin:Coin = .Heads
let secondCoin = Coin.Tails
let thirdCoin = .Heads // not allowed

The apparent inconsistency seems to stem from the compiler doing an implicit equivalent of:

let heads = Coin.heads
let tails = Coin.tails

If one define these on its own at a global level, the same inconsistent use of the leading dot is present everywhere.

I’m thinking that the proposal as stated "mandate leading dot" is wrong, it should be redone as "prevent direct access to the implicit static let auto-generated for the enum case within the enum declaration". Unfortunately, I do not know if there are legit use of this implicit static let in the wild.

This way, for the staticFunc2 we get:

static func staticFunc2() { let foo = Coin.Tails } // Acceptable
static func staticFunc2() { let foo:Coin = .Tails } // Acceptable
static func staticFunc2() { let foo = Tails } // New error, no longer accessible
static func staticFunc2() { let foo = .Tails } // Current error, ambiguous

Dany

···

Le 13 févr. 2016 à 15:29, David Waite via swift-evolution <swift-evolution@swift.org> a écrit :

Is your proposal to:
- require a dot in front of static properties/functions in this case as well for consistency across all static things
- require a dot only in front of the case statements, to promote consistency only for use of cases within an enum
- or, do you wish to change your mind about this particular case?

-DW

On Feb 13, 2016, at 12:31 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

No. The wildcard match does not require a dot prefix.

-- E

On Feb 13, 2016, at 10:40 AM, Paul Ossenbruggen via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

I am assuming there would be no dot in front of _?

switch value {
  case .A: “A”
  case .B: “B”
  case ._:”D” // this is not correct?
}

On Feb 13, 2016, at 9:18 AM, Joseph Lord via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

+1

Didn't even know it was legal. Definitely increases consistency and simplifies the language.

J

On Feb 12, 2016, at 3:00 AM, Erica Sadun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

enums.md · GitHub

Requiring Leading Dot Prefixes for Enum Instance Member Implementations

_______________________________________________
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

_______________________________________________
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
https://lists.swift.org/mailman/listinfo/swift-evolution

+1 for the proposal, it is wierd to use `.` in some places and not others.

On the subject of static methods and properties in general, would it be
possible for `.name` to be a reference to a static and `name` a reference
to an instance? EG:

    .name = x // static
    name = x // instance
    x = name + .name // instance + static
    r = name ... .name // instance ... static, needs space
    r = name...Type.name // Can still qualify with type name

···

On Friday, 12 February 2016, Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote:

On Feb 11, 2016, at 7:17 PM, Rob Mayoff via swift-evolution < > swift-evolution@swift.org > <javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>> wrote:

On Thu, Feb 11, 2016 at 9:00 PM, Erica Sadun via swift-evolution < > swift-evolution@swift.org > <javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>> wrote:

Unlike static members in structures and classes, enumeration cases can be
mentioned in initializers and instance methods without referencing a fully
qualified type.

Why not go the other way then and allow instance methods to refer to
static members (or class members) directly, without the type name prefix?

As Erica says, this is a worthwhile topic to discuss, but orthogonal from
the proposal. Among other things we’d have to have a way to resolve the
conflict that comes up when you have both a static and instance method with
the same name (this occurs a few places in ObjC APIs).

-Chris

--
-- Howard.

Completely agree with this.

-David

···

On Feb 12, 2016, at 7:57 AM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:

Are there any reasons why it makes sense to add them to the declaration? There's no other place in the language where a member is declared (vs referenced) using a dot prefix so I'd personally lean towards "no".

I see your point and I agree. I agree with the proposal as it. Thanks Erica.

— Carlos Parada

···

On Feb 12, 2016, at 7:57 AM, Erica Sadun <erica@ericasadun.com> wrote:

Are there any reasons why it makes sense to add them to the declaration? There's no other place in the language where a member is declared (vs referenced) using a dot prefix so I'd personally lean towards "no".

-- Erica

On Feb 11, 2016, at 11:41 PM, Carlos Parada <carlosparada@me.com <mailto:carlosparada@me.com>> wrote:

Taking consistency further, should the definition also use dot prefixes? For example:

enum Coin {
    case .Heads, .Tails
    func printMe() {
        switch self {
        case .Heads: print("Heads")
        case .Tails: print("Tails")
        }
    }
}

— Carlos Parada

I would be against that. I like being able to use static members with shorthand.

textField.font = .systemFontOfSize(48)

switch point {
case .zero:
  print("origin")
case _ where point.x < 0:
  print("negative x")
default:
  print("uninteresting")
}

Jordan

···

On Feb 11, 2016, at 22:27 , David Waite via swift-evolution <swift-evolution@swift.org> wrote:

Would it be worthwhile to expand this (or create another proposal) to deal with switch cases only allowing dot syntax for use with enum cases?

Pull request: Requiring Leading Dot Prefixes for Enum Instance Member Implementations by erica · Pull Request #153 · apple/swift-evolution · GitHub

···

On Feb 12, 2016, at 10:23 AM, Chris Lattner <clattner@apple.com> wrote:

On Feb 11, 2016, at 8:09 PM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:

enums.md · GitHub

Requiring Leading Dot Prefixes for Enum Instance Member Implementations

  • Proposal: TBD
  • Author(s): Erica Sadun, Chris Lattner
  • Status: TBD
  • Review manager: TBD

+1. I've always found this slightly bizarre.

I assume, though, that if you're writing a static member of an enum, the unprefixed form is fine?

Yes, that makes sense to me.

-Chris

The honest and lazy truth? Muscle memory. I type `case .<Foo>` much more
than `case <Foo>` so I tend to pause during declaration more often than I
would like. I can let it go now that I have floated the idea but that was
the reason I pitched it.
TJ

···

On Fri, Feb 12, 2016 at 10:57 AM, Erica Sadun via swift-evolution < swift-evolution@swift.org> wrote:

Are there any reasons why it makes sense to add them to the declaration?
There's no other place in the language where a member is declared (vs
referenced) using a dot prefix so I'd personally lean towards "no".

-- Erica

On Feb 11, 2016, at 11:41 PM, Carlos Parada <carlosparada@me.com> wrote:

Taking consistency further, should the definition also use dot prefixes?
For example:

enum Coin {
    case .Heads, .Tails
    func printMe() {
        switch self {
        case .Heads: print("Heads")
        case .Tails: print("Tails")
        }
    }
}

— Carlos Parada

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

Dany,

I've already updated my working copy of the proposal to change that to not requiring the leading dot based on feedback.

-- E

···

On Feb 14, 2016, at 6:24 AM, Dany St-Amant via swift-evolution <swift-evolution@swift.org> wrote:

Le 13 févr. 2016 à 15:29, David Waite via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> a écrit :

Erica,

The current spec has the following line:

static func staticFunc2() { let foo = .Tails } // requires leading dot

The leading dot requirement does not exist today for references to static properties and functions from a static function.

After focusing on this line and on the error we get back when trying it now in playground, I no longer see the reported inconsistent as such, but just as a clash of two permissible syntax, which if changed as proposed will just swap an inconsistency for another one.

For those wondering, the reported error is: type of expression is ambiguous without more context

The shorthand syntax is to be used when the compiler, and the programmer knows what the type is. In the above example, why should the compile infer that variable foo is of type Coin. It would make more sense for that particular function to be:

static func staticFunc2() { let foo = Coin.Tails }
static func staticFunc2() { let foo:Coin = .Tails }

And be consistent with (both at a global scope or as static inside the enum):

let firstCoin:Coin = .Heads
let secondCoin = Coin.Tails
let thirdCoin = .Heads // not allowed

The apparent inconsistency seems to stem from the compiler doing an implicit equivalent of:

let heads = Coin.heads
let tails = Coin.tails

If one define these on its own at a global level, the same inconsistent use of the leading dot is present everywhere.

I’m thinking that the proposal as stated "mandate leading dot" is wrong, it should be redone as "prevent direct access to the implicit static let auto-generated for the enum case within the enum declaration". Unfortunately, I do not know if there are legit use of this implicit static let in the wild.

This way, for the staticFunc2 we get:

static func staticFunc2() { let foo = Coin.Tails } // Acceptable
static func staticFunc2() { let foo:Coin = .Tails } // Acceptable
static func staticFunc2() { let foo = Tails } // New error, no longer accessible
static func staticFunc2() { let foo = .Tails } // Current error, ambiguous

Dany

Is your proposal to:
- require a dot in front of static properties/functions in this case as well for consistency across all static things
- require a dot only in front of the case statements, to promote consistency only for use of cases within an enum
- or, do you wish to change your mind about this particular case?

-DW

On Feb 13, 2016, at 12:31 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

No. The wildcard match does not require a dot prefix.

-- E

On Feb 13, 2016, at 10:40 AM, Paul Ossenbruggen via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

I am assuming there would be no dot in front of _?

switch value {
  case .A: “A”
  case .B: “B”
  case ._:”D” // this is not correct?
}

On Feb 13, 2016, at 9:18 AM, Joseph Lord via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

+1

Didn't even know it was legal. Definitely increases consistency and simplifies the language.

J

On Feb 12, 2016, at 3:00 AM, Erica Sadun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

enums.md · GitHub

Requiring Leading Dot Prefixes for Enum Instance Member Implementations

_______________________________________________
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

_______________________________________________
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

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

I think you may have misunderstood - I’m asking if we can make your switch example into legal code :-)

var point = CGPoint.zero

switch point {
case .zero: // Error: Enum case 'zero' not found in type 'CGPoint'

-DW

···

On Feb 12, 2016, at 10:57 AM, Jordan Rose <jordan_rose@apple.com> wrote:

On Feb 11, 2016, at 22:27 , David Waite via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Would it be worthwhile to expand this (or create another proposal) to deal with switch cases only allowing dot syntax for use with enum cases?

I would be against that. I like being able to use static members with shorthand.

textField.font = .systemFontOfSize(48)

switch point {
case .zero:
  print("origin")
case _ where point.x < 0:
  print("negative x")
default:
  print("uninteresting")
}

Jordan

p.s. https://github.com/erica/swift-evolution/blob/master/proposals/00XX-enum-dot.md

-- E

···

On Feb 14, 2016, at 8:29 AM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:

Dany,

I've already updated my working copy of the proposal to change that to not requiring the leading dot based on feedback.

-- E

On Feb 14, 2016, at 6:24 AM, Dany St-Amant via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Le 13 févr. 2016 à 15:29, David Waite via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> a écrit :

Erica,

The current spec has the following line:

static func staticFunc2() { let foo = .Tails } // requires leading dot

The leading dot requirement does not exist today for references to static properties and functions from a static function.

After focusing on this line and on the error we get back when trying it now in playground, I no longer see the reported inconsistent as such, but just as a clash of two permissible syntax, which if changed as proposed will just swap an inconsistency for another one.

For those wondering, the reported error is: type of expression is ambiguous without more context

The shorthand syntax is to be used when the compiler, and the programmer knows what the type is. In the above example, why should the compile infer that variable foo is of type Coin. It would make more sense for that particular function to be:

static func staticFunc2() { let foo = Coin.Tails }
static func staticFunc2() { let foo:Coin = .Tails }

And be consistent with (both at a global scope or as static inside the enum):

let firstCoin:Coin = .Heads
let secondCoin = Coin.Tails
let thirdCoin = .Heads // not allowed

The apparent inconsistency seems to stem from the compiler doing an implicit equivalent of:

let heads = Coin.heads
let tails = Coin.tails

If one define these on its own at a global level, the same inconsistent use of the leading dot is present everywhere.

I’m thinking that the proposal as stated "mandate leading dot" is wrong, it should be redone as "prevent direct access to the implicit static let auto-generated for the enum case within the enum declaration". Unfortunately, I do not know if there are legit use of this implicit static let in the wild.

This way, for the staticFunc2 we get:

static func staticFunc2() { let foo = Coin.Tails } // Acceptable
static func staticFunc2() { let foo:Coin = .Tails } // Acceptable
static func staticFunc2() { let foo = Tails } // New error, no longer accessible
static func staticFunc2() { let foo = .Tails } // Current error, ambiguous

Dany

Is your proposal to:
- require a dot in front of static properties/functions in this case as well for consistency across all static things
- require a dot only in front of the case statements, to promote consistency only for use of cases within an enum
- or, do you wish to change your mind about this particular case?

-DW

On Feb 13, 2016, at 12:31 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

No. The wildcard match does not require a dot prefix.

-- E

On Feb 13, 2016, at 10:40 AM, Paul Ossenbruggen via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

I am assuming there would be no dot in front of _?

switch value {
  case .A: “A”
  case .B: “B”
  case ._:”D” // this is not correct?
}

On Feb 13, 2016, at 9:18 AM, Joseph Lord via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

+1

Didn't even know it was legal. Definitely increases consistency and simplifies the language.

J

On Feb 12, 2016, at 3:00 AM, Erica Sadun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

enums.md · GitHub

Requiring Leading Dot Prefixes for Enum Instance Member Implementations

_______________________________________________
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

_______________________________________________
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

_______________________________________________
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
https://lists.swift.org/mailman/listinfo/swift-evolution

But the dot prefix is not a specificity of enum cases: it’s the case (no pun intended) for all static members. So I don’t understand why you would suggest using it for the declaration of enum cases. It would un-necessarily tie dot prefix with Enums and hide for newcomers the fact it can also be used for other static members.

···

On 13 Feb 2016, at 19:02, T.J. Usiyan via swift-evolution <swift-evolution@swift.org> wrote:

The honest and lazy truth? Muscle memory. I type `case .<Foo>` much more than `case <Foo>` so I tend to pause during declaration more often than I would like. I can let it go now that I have floated the idea but that was the reason I pitched it.
TJ

On Fri, Feb 12, 2016 at 10:57 AM, Erica Sadun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Are there any reasons why it makes sense to add them to the declaration? There's no other place in the language where a member is declared (vs referenced) using a dot prefix so I'd personally lean towards "no".

-- Erica

On Feb 11, 2016, at 11:41 PM, Carlos Parada <carlosparada@me.com <mailto:carlosparada@me.com>> wrote:

Taking consistency further, should the definition also use dot prefixes? For example:

enum Coin {
    case .Heads, .Tails
    func printMe() {
        switch self {
        case .Heads: print("Heads")
        case .Tails: print("Tails")
        }
    }
}

— Carlos Parada

_______________________________________________
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
https://lists.swift.org/mailman/listinfo/swift-evolution

That's a bug.

-Joe

···

On Feb 12, 2016, at 10:24 AM, David Waite via swift-evolution <swift-evolution@swift.org> wrote:

I think you may have misunderstood - I’m asking if we can make your switch example into legal code :-)

var point = CGPoint.zero

switch point {
case .zero: // Error: Enum case 'zero' not found in type 'CGPoint'

Ah, I misread that as you wanting to enforce it rather than allow it! I'm with Joe; we can just consider that a bug. Mind filing it on bugs.swift.org?

Jordan

···

On Feb 12, 2016, at 10:24, David Waite <david@alkaline-solutions.com> wrote:

I think you may have misunderstood - I’m asking if we can make your switch example into legal code :-)

var point = CGPoint.zero

switch point {
case .zero: // Error: Enum case 'zero' not found in type 'CGPoint'

-DW

On Feb 12, 2016, at 10:57 AM, Jordan Rose <jordan_rose@apple.com <mailto:jordan_rose@apple.com>> wrote:

On Feb 11, 2016, at 22:27 , David Waite via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Would it be worthwhile to expand this (or create another proposal) to deal with switch cases only allowing dot syntax for use with enum cases?

I would be against that. I like being able to use static members with shorthand.

textField.font = .systemFontOfSize(48)

switch point {
case .zero:
  print("origin")
case _ where point.x < 0:
  print("negative x")
default:
  print("uninteresting")
}

Jordan

You got it. SR-719 and also SR-720.

-DW

···

On Feb 12, 2016, at 12:18 PM, Jordan Rose <jordan_rose@apple.com> wrote:

Ah, I misread that as you wanting to enforce it rather than allow it! I'm with Joe; we can just consider that a bug. Mind filing it on bugs.swift.org <Issues · apple/swift · GitHub?

Jordan

On Feb 12, 2016, at 10:24, David Waite <david@alkaline-solutions.com <mailto:david@alkaline-solutions.com>> wrote:

I think you may have misunderstood - I’m asking if we can make your switch example into legal code :-)

var point = CGPoint.zero

switch point {
case .zero: // Error: Enum case 'zero' not found in type 'CGPoint'

-DW

On Feb 12, 2016, at 10:57 AM, Jordan Rose <jordan_rose@apple.com <mailto:jordan_rose@apple.com>> wrote:

On Feb 11, 2016, at 22:27 , David Waite via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Would it be worthwhile to expand this (or create another proposal) to deal with switch cases only allowing dot syntax for use with enum cases?

I would be against that. I like being able to use static members with shorthand.

textField.font = .systemFontOfSize(48)

switch point {
case .zero:
  print("origin")
case _ where point.x < 0:
  print("negative x")
default:
  print("uninteresting")
}

Jordan

+1 for this proposal.
/Jens

···

On Fri, Feb 12, 2016 at 8:18 PM, Jordan Rose via swift-evolution < swift-evolution@swift.org> wrote:

Ah, I misread that as you wanting to *enforce* it rather than *allow* it!
I'm with Joe; we can just consider that a bug. Mind filing it on
bugs.swift.org?

Jordan

On Feb 12, 2016, at 10:24, David Waite <david@alkaline-solutions.com> > wrote:

I think you may have misunderstood - I’m asking if we can make your switch
example into legal code :-)

var point = CGPoint.zero

switch point {
case .zero: // Error: Enum case 'zero' not found in type 'CGPoint'

-DW

On Feb 12, 2016, at 10:57 AM, Jordan Rose <jordan_rose@apple.com> wrote:

On Feb 11, 2016, at 22:27 , David Waite via swift-evolution < > swift-evolution@swift.org> wrote:

Would it be worthwhile to expand this (or create another proposal) to deal
with switch cases only allowing dot syntax for use with enum cases?

I would be against that. I like being able to use static members with
shorthand.

textField.font = .systemFontOfSize(48)

switch point {
case .zero:
  print("origin")
case _ where point.x < 0:
  print("negative x")
default:
  print("uninteresting")
}

Jordan

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

--
bitCycle AB | Smedjegatan 12 | 742 32 Östhammar | Sweden

Phone: +46-73-753 24 62
E-mail: jens@bitcycle.com