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
···
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.
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?
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.
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
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.
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.
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.
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
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?
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.
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
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?
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.
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>
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.
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: