Dotless case names in switch cases


(Jens Persson) #1

enum SomeEnum {
    case Foo
    case Bar
    func demoDotAndNoDot() {
        switch self {
        case .Foo: print("This has the usual dot before the case name.")
        case Bar: print("This has no dot, which is ok, at least in this
particular context.")
        }
    }
}

I'm just throwing this out in case someone should feel like writing a
formal proposal to remove the dotless form.

I'd be ok with removing it since it only works in some specific contexts.

/Jens


(Joe Groff) #2

This works by normal instance member lookup. Why do you think it should be removed?

-Joe

···

On Jan 15, 2016, at 2:44 PM, Jens Persson via swift-evolution <swift-evolution@swift.org> wrote:

enum SomeEnum {
    case Foo
    case Bar
    func demoDotAndNoDot() {
        switch self {
        case .Foo: print("This has the usual dot before the case name.")
        case Bar: print("This has no dot, which is ok, at least in this particular context.")
        }
    }
}

I'm just throwing this out in case someone should feel like writing a formal proposal to remove the dotless form.

I'd be ok with removing it since it only works in some specific contexts.


(Nate Cook) #3

There's a fairly subtle difference between `case Foo` and `case let Foo` when using a switch inside an enumeration. The first matches the Foo case of the current enumeration, the second binds a local `Foo` (that shadows .Foo) to any case. See the `testLet` property in this example:

enum Test {
    case One, Two
    
    var testDot: String {
        switch self {
        case .One: return "One"
        case .Two: return "Two"
        }
    }
    
    var testLetDot: String {
        switch self {
        case let .One: return "One"
        case let .Two: return "Two"
        }
    }
    
    var testLet: String {
        switch self {
        case let One: return "One" // Danger Will Robinson
        case let Two: return "Two"
        }
    }
    
    var testNone: String {
        switch self {
        case One: return "One"
        case Two: return "Two"
        }
    }
}

let two = Test.Two
two.testDot // Two
two.testLetDot // Two
two.testLet // One
two.testNone // Two

···

On Jan 15, 2016, at 6:42 PM, Joe Groff via swift-evolution <swift-evolution@swift.org> wrote:

On Jan 15, 2016, at 2:44 PM, Jens Persson via swift-evolution <swift-evolution@swift.org> wrote:

enum SomeEnum {
   case Foo
   case Bar
   func demoDotAndNoDot() {
       switch self {
       case .Foo: print("This has the usual dot before the case name.")
       case Bar: print("This has no dot, which is ok, at least in this particular context.")
       }
   }
}

I'm just throwing this out in case someone should feel like writing a formal proposal to remove the dotless form.

I'd be ok with removing it since it only works in some specific contexts.

This works by normal instance member lookup. Why do you think it should be removed?

-Joe

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


(Jens Persson) #4

I see, I never thought of the case names as being instance-member-like, and
I thought it would be simpler to just have one form for the switch cases
(the one with a dot before the case name).

I don't want the dotless form to be removed if it complicates rather than
simplifies the (compiler) code.

( My mail was a reaction to this tweet / conversation:
https://twitter.com/UINT_MIN/status/688101066668281856 )

···

On Sat, Jan 16, 2016 at 1:42 AM, Joe Groff <jgroff@apple.com> wrote:

> On Jan 15, 2016, at 2:44 PM, Jens Persson via swift-evolution < > swift-evolution@swift.org> wrote:
>
> enum SomeEnum {
> case Foo
> case Bar
> func demoDotAndNoDot() {
> switch self {
> case .Foo: print("This has the usual dot before the case name.")
> case Bar: print("This has no dot, which is ok, at least in this
particular context.")
> }
> }
> }
>
> I'm just throwing this out in case someone should feel like writing a
formal proposal to remove the dotless form.
>
> I'd be ok with removing it since it only works in some specific contexts.

This works by normal instance member lookup. Why do you think it should be
removed?

-Joe

--
bitCycle AB | Smedjegatan 12 | 742 32 Östhammar | Sweden
http://www.bitcycle.com/
Phone: +46-73-753 24 62
E-mail: jens@bitcycle.com


(Brent Royal-Gordon) #5

This works by normal instance member lookup. Why do you think it should be removed?

Wait, why would the case be an instance member? Isn't it equivalent to a static member?

···

--
Brent Royal-Gordon
Architechies


(Zhao Xin) #6

let Foo:SomeEnum = .Bar
let Bar:SomeEnum = .Foo

enum SomeEnum {
    case Foo
    case Bar
    func demoDotAndNoDot() {
        switch self {
        case .Foo: print("This has the usual dot before the case name.")
        case .Bar: print("This has no dot, which is ok, at least in this
particular context.")
        }
    }
}

above code works in current Swift. It will not work after your changes.

zhaoxin

···

On Sat, Jan 16, 2016 at 6:44 AM, Jens Persson via swift-evolution < swift-evolution@swift.org> wrote:

enum SomeEnum {
    case Foo
    case Bar
    func demoDotAndNoDot() {
        switch self {
        case .Foo: print("This has the usual dot before the case name.")
        case Bar: print("This has no dot, which is ok, at least in this
particular context.")
        }
    }
}

I'm just throwing this out in case someone should feel like writing a
formal proposal to remove the dotless form.

I'd be ok with removing it since it only works in some specific contexts.

/Jens

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

--

Owen Zhao


(Howard Lovatt) #7

-1, not worth changing

···

On Saturday, 16 January 2016, Jens Persson via swift-evolution < swift-evolution@swift.org> wrote:

enum SomeEnum {
    case Foo
    case Bar
    func demoDotAndNoDot() {
        switch self {
        case .Foo: print("This has the usual dot before the case name.")
        case Bar: print("This has no dot, which is ok, at least in this
particular context.")
        }
    }
}

I'm just throwing this out in case someone should feel like writing a
formal proposal to remove the dotless form.

I'd be ok with removing it since it only works in some specific contexts.

/Jens

--
  -- Howard.


(Charles Constant) #8

-1

I think this would make autocompletion in Xcode more complicated. I like
seeing a list of all enum cases when I start typing

···

On Fri, Jan 15, 2016 at 5:05 PM, Jens Persson via swift-evolution < swift-evolution@swift.org> wrote:

I see, I never thought of the case names as being instance-member-like,
and I thought it would be simpler to just have one form for the switch
cases (the one with a dot before the case name).

I don't want the dotless form to be removed if it complicates rather than
simplifies the (compiler) code.

( My mail was a reaction to this tweet / conversation:
https://twitter.com/UINT_MIN/status/688101066668281856 )

On Sat, Jan 16, 2016 at 1:42 AM, Joe Groff <jgroff@apple.com> wrote:

> On Jan 15, 2016, at 2:44 PM, Jens Persson via swift-evolution < >> swift-evolution@swift.org> wrote:
>
> enum SomeEnum {
> case Foo
> case Bar
> func demoDotAndNoDot() {
> switch self {
> case .Foo: print("This has the usual dot before the case name.")
> case Bar: print("This has no dot, which is ok, at least in this
particular context.")
> }
> }
> }
>
> I'm just throwing this out in case someone should feel like writing a
formal proposal to remove the dotless form.
>
> I'd be ok with removing it since it only works in some specific
contexts.

This works by normal instance member lookup. Why do you think it should
be removed?

-Joe

--
bitCycle AB | Smedjegatan 12 | 742 32 Östhammar | Sweden
http://www.bitcycle.com/
Phone: +46-73-753 24 62
E-mail: jens@bitcycle.com

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


(Joe Groff) #9

There's a fairly subtle difference between `case Foo` and `case let Foo` when using a switch inside an enumeration. The first matches the Foo case of the current enumeration, the second binds a local `Foo` (that shadows .Foo) to any case. See the `testLet` property in this example:

enum Test {
    case One, Two
    
    var testDot: String {
        switch self {
        case .One: return "One"
        case .Two: return "Two"
        }
    }
    
    var testLetDot: String {
        switch self {
        case let .One: return "One"
        case let .Two: return "Two"
        }
    }
    
    var testLet: String {
        switch self {
        case let One: return "One" // Danger Will Robinson
        case let Two: return "Two"
        }
    }
    
    var testNone: String {
        switch self {
        case One: return "One"
        case Two: return "Two"
        }
    }
}

let two = Test.Two
two.testDot // Two
two.testLetDot // Two
two.testLet // One
two.testNone // Two

Definitely, Rob Rix has run into this problem in the wild too. I think that's a general ergonomic problem with our pattern syntax, though; 'let' on every pattern variable is verbose, and it's tempting when doing heavy pattern matching to reflexively type 'case let' at the start of every match to avoid it.

-Joe

···

On Jan 15, 2016, at 11:56 PM, Nate Cook <natecook@gmail.com> wrote:

On Jan 15, 2016, at 6:42 PM, Joe Groff via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Jan 15, 2016, at 2:44 PM, Jens Persson via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

enum SomeEnum {
   case Foo
   case Bar
   func demoDotAndNoDot() {
       switch self {
       case .Foo: print("This has the usual dot before the case name.")
       case Bar: print("This has no dot, which is ok, at least in this particular context.")
       }
   }
}

I'm just throwing this out in case someone should feel like writing a formal proposal to remove the dotless form.

I'd be ok with removing it since it only works in some specific contexts.

This works by normal instance member lookup. Why do you think it should be removed?

-Joe

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


(Jens Persson) #10

I wish I had written the title: "Remove dotless form of case names in
switch cases".
To clearify: I want the usual form with a dot to stay, and I think the more
unusual variant without the dot could be removed to solve the problem
demonstrated by Nate's example program and to simplify things (so that
there's just one way to write these things (always with a dot before the
case name)).
/Jens

···

On Sat, Jan 16, 2016 at 8:23 AM, Charles Constant <charles@charlesism.com> wrote:

-1

I think this would make autocompletion in Xcode more complicated. I like
seeing a list of all enum cases when I start typing

On Fri, Jan 15, 2016 at 5:05 PM, Jens Persson via swift-evolution < > swift-evolution@swift.org> wrote:

I see, I never thought of the case names as being instance-member-like,
and I thought it would be simpler to just have one form for the switch
cases (the one with a dot before the case name).

I don't want the dotless form to be removed if it complicates rather than
simplifies the (compiler) code.

( My mail was a reaction to this tweet / conversation:
https://twitter.com/UINT_MIN/status/688101066668281856 )

On Sat, Jan 16, 2016 at 1:42 AM, Joe Groff <jgroff@apple.com> wrote:

> On Jan 15, 2016, at 2:44 PM, Jens Persson via swift-evolution < >>> swift-evolution@swift.org> wrote:
>
> enum SomeEnum {
> case Foo
> case Bar
> func demoDotAndNoDot() {
> switch self {
> case .Foo: print("This has the usual dot before the case
name.")
> case Bar: print("This has no dot, which is ok, at least in
this particular context.")
> }
> }
> }
>
> I'm just throwing this out in case someone should feel like writing a
formal proposal to remove the dotless form.
>
> I'd be ok with removing it since it only works in some specific
contexts.

This works by normal instance member lookup. Why do you think it should
be removed?

-Joe

--
bitCycle AB | Smedjegatan 12 | 742 32 Östhammar | Sweden
http://www.bitcycle.com/
Phone: +46-73-753 24 62
E-mail: jens@bitcycle.com

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

--
bitCycle AB | Smedjegatan 12 | 742 32 Östhammar | Sweden
http://www.bitcycle.com/
Phone: +46-73-753 24 62
E-mail: jens@bitcycle.com


(Chris Lattner) #11

Yes. IMO, it should only be found by unqualified lookup when in a static member.

This has always bugged me :-(

-Chris

···

On Jan 16, 2016, at 2:29 AM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:

This works by normal instance member lookup. Why do you think it should be removed?

Wait, why would the case be an instance member? Isn't it equivalent to a static member?


(Joe Groff) #12

You're right, sorry. This is really a holdover from early versions of the compiler where we did 'static' lookup from instance scope. It would be more consistent to disallow it, I agree.

-Joe

···

On Jan 16, 2016, at 2:29 AM, Brent Royal-Gordon <brent@architechies.com> wrote:

This works by normal instance member lookup. Why do you think it should be removed?

Wait, why would the case be an instance member? Isn't it equivalent to a static member?


(Jordan Rose) #13

My opinion was that there's two ways to spell this, and that we ought to steer people towards being consistent. (We actually have special code right now so that the dotless reference can still be used for exhaustive matching.)

Either it's more consistent to allow it (because it's just another expression) or it's more consistent to disallow it (because it's not how you'd write the member in any other switch, and it's only one character of difference).

Jordan

···

On Jan 15, 2016, at 17:05, Jens Persson via swift-evolution <swift-evolution@swift.org> wrote:

I see, I never thought of the case names as being instance-member-like, and I thought it would be simpler to just have one form for the switch cases (the one with a dot before the case name).

I don't want the dotless form to be removed if it complicates rather than simplifies the (compiler) code.

( My mail was a reaction to this tweet / conversation:
https://twitter.com/UINT_MIN/status/688101066668281856 )

On Sat, Jan 16, 2016 at 1:42 AM, Joe Groff <jgroff@apple.com <mailto:jgroff@apple.com>> wrote:

> On Jan 15, 2016, at 2:44 PM, Jens Persson via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>
> enum SomeEnum {
> case Foo
> case Bar
> func demoDotAndNoDot() {
> switch self {
> case .Foo: print("This has the usual dot before the case name.")
> case Bar: print("This has no dot, which is ok, at least in this particular context.")
> }
> }
> }
>
> I'm just throwing this out in case someone should feel like writing a formal proposal to remove the dotless form.
>
> I'd be ok with removing it since it only works in some specific contexts.

This works by normal instance member lookup. Why do you think it should be removed?

-Joe

--
bitCycle AB | Smedjegatan 12 | 742 32 Östhammar | Sweden
http://www.bitcycle.com/
Phone: +46-73-753 24 62
E-mail: jens@bitcycle.com <mailto:jens@bitcycle.com>

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


(Charles Srstka) #14

That could be fixed by getting rid of “case let”, though, and just putting the “let” next to the actual variable name:

case .Foo(let bar):

instead of:

case let .Foo(bar):

It seems a little more consistent with Swift’s type system in general, and it actually works today (at least, it did in the playground I just tried it in). And since it’s entered at the same time as you’re entering a variable name into the parens, it’s less likely to provoke that “argh, I forgot to put the left bracket on my Objective-C method” feeling that could cause one to reflexively type “case let” in the first place.

Charles

···

On Jan 16, 2016, at 1:20 PM, Joe Groff via swift-evolution <swift-evolution@swift.org> wrote:

Definitely, Rob Rix has run into this problem in the wild too. I think that's a general ergonomic problem with our pattern syntax, though; 'let' on every pattern variable is verbose, and it's tempting when doing heavy pattern matching to reflexively type 'case let' at the start of every match to avoid it.


(Matthew Johnson) #15

This works by normal instance member lookup. Why do you think it should be removed?

Wait, why would the case be an instance member? Isn't it equivalent to a static member?

You're right, sorry. This is really a holdover from early versions of the compiler where we did 'static' lookup from instance scope. It would be more consistent to disallow it, I agree.

I was just thinking over the weekend that it would be nice if it was possible to have static helper methods that weren’t at a syntactic disadvantage when called from instance methods.

Interesting that this used to be the case. Why was it removed? Problems like this one?

Have you considered allowing types to be explicitly “opened” in a scope, making static members available as if they were defined at the top-level?

-Matthew

···

On Jan 18, 2016, at 10:42 AM, Joe Groff via swift-evolution <swift-evolution@swift.org> wrote:

On Jan 16, 2016, at 2:29 AM, Brent Royal-Gordon <brent@architechies.com> wrote:

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