[Idea] Find alternatives to `switch self`

(tl;dr: will Swift 3.0 improve iteration for enum values? Some kind of .next() method for values or .all property. Currently we have a problem with this.)

There are proposals to do this, but they're on hold at the moment because the guy who was the main driving force got busy with meatspace things. Roughly, you would be able to conform an enum to a ValuesEnumerable protocol which would automatically synthesize an `allValues` static property on it. You could use an extension to do this to an enum that didn't belong to you, so you could get this even if the original author didn't think to add it.

···

--
Brent Royal-Gordon
Architechies

Could you provide a little more information about this ValuesEnumerable protocol? My Swift says it doesn't know about such protocol.
Strange, but goggle knows nothing about
'swift "ValuesEnumerable"'
But I can see ValuesEnumerable in some articles related to C#.

···

On 09.04.2016 6:49, Brent Royal-Gordon wrote:

(tl;dr: will Swift 3.0 improve iteration for enum values? Some kind of .next() method for values or .all property. Currently we have a problem with this.)

There are proposals to do this, but they're on hold at the moment because the guy who was the main driving force got busy with meatspace things. Roughly, you would be able to conform an enum to a ValuesEnumerable protocol which would automatically synthesize an `allValues` static property on it. You could use an extension to do this to an enum that didn't belong to you, so you could get this even if the original author didn't think to add it.

(tl;dr: will Swift 3.0 improve iteration for enum values? Some kind of .next() method for values or .all property. Currently we have a problem with this.)

There are proposals to do this, but they're on hold at the moment because the guy who was the main driving force got busy with meatspace things. Roughly, you would be able to conform an enum to a ValuesEnumerable protocol which would automatically synthesize an `allValues` static property on it. You could use an extension to do this to an enum that didn't belong to you, so you could get this even if the original author didn't think to add it.

Could you provide a little more information about this ValuesEnumerable protocol? My Swift says it doesn't know about such protocol.
Strange, but goggle knows nothing about
'swift "ValuesEnumerable"'
But I can see ValuesEnumerable in some articles related to C#.

This design is still very much under development—it hasn't even been reviewed, let alone added to the language. Here's the draft proposal: <https://github.com/jtbandes/swift-evolution/blob/case-enumerable/proposals/0000-derived-collection-of-enum-cases.md&gt;

I'm not saying that this will necessarily be a solution that ends up being accepted—I'm merely saying that yes, it's something people are thinking about and designing; it's just been inactive for a few weeks.

···

--
Brent Royal-Gordon
Architechies

Oh, I see. Thank you for letting know. Just missed "you would be able" in your previous message, did read it as "you are able", so was trying to find this in current Swift version. OK, glad to know that most likely we'll have improvements in enums eterations for Swift 3.0.

···

On 09.04.2016 9:31, Brent Royal-Gordon wrote:

This design is still very much under development�it hasn't even been reviewed, let alone added to the language. Here's the draft proposal:<https://github.com/jtbandes/swift-evolution/blob/case-enumerable/proposals/0000-derived-collection-of-enum-cases.md&gt;

I'm not saying that this will necessarily be a solution that ends up being accepted�I'm merely saying that yes, it's something people are thinking about and designing; it's just been inactive for a few weeks.

I wrote some code tonight to experiment with this kind of thing. I
apologize if it's off-topic for the thread, but it might be useful to
others who want to experiment.

//: Playground - noun: a place where people can play

import Cocoa

infix operator • { precedence 180 }

infix operator → { associativity left precedence 70 }

infix operator … { associativity right precedence 60 }

func → <T>( lhs: Bool, rhs: T ) -> T? {

return lhs ? rhs : nil

}

func … <T>( lhs:T?, rhs:T ) -> T {

return lhs != nil ? lhs! : rhs

}

func depends<I,O>( dep:I, _ closure: (I)->(O) ) -> O {

return closure( dep )

}

func • <I,O>( lhs: I, rhs: (I)->(O) ) -> O {

return depends( lhs, rhs )

}

/* Example using "depends" */

let

str:String,

i = 7

str = depends( i ){

$0==2 → "two" …

$0==3 → "three" …

$0==4 → "four" …

"other"

}

/* Example using "•" operator as "depends" */

enum People { case Kurtz, Popescu, Lime, Martins }

enum Order { case First, Second, Third, Unknown }

let

order:Order,

person:People = .Lime

order = person • {

$0 == .Kurtz → .First …

$0 == .Popescu → .Second …

$0 == .Lime → .Third …

.Unknown

}

I also have some trepidation about posting it here, because it might have
bugs. I wans't sure what "precedence" and "associativity" should be, for
example. But it does make it more convenient to test alternative characters
for operators, etc.

···

On Sat, Apr 9, 2016 at 12:05 AM, Vladimir.S via swift-evolution < swift-evolution@swift.org> wrote:

On 09.04.2016 9:31, Brent Royal-Gordon wrote:

This design is still very much under development—it hasn't even been
reviewed, let alone added to the language. Here's the draft proposal:<
https://github.com/jtbandes/swift-evolution/blob/case-enumerable/proposals/0000-derived-collection-of-enum-cases.md
>

I'm not saying that this will necessarily be a solution that ends up
being accepted—I'm merely saying that yes, it's something people are
thinking about and designing; it's just been inactive for a few weeks.

Oh, I see. Thank you for letting know. Just missed "you would be able" in
your previous message, did read it as "you are able", so was trying to find
this in current Swift version. OK, glad to know that most likely we'll have
improvements in enums eterations for Swift 3.0.

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

This is very similar to Haskell's guard I tried to pitch before, but the community seem to not want it on Swift.

let a | case1 = "case 1"
      > case2 = "case 2"
      > otherwise = "default"

Where otherwise is simply defined as otherwise = True that catches everything (similar to switch default)

On behalf of the OP's:

var description: String {
    case .Hearts:
        return ":heart:"
    case .Spades:
        return ":spades:"
    case .Diamonds:
        return ":diamonds:"
    case .Clubs:
        return ":clubs:"
}

can be:

var description: String {
    return | .Hearts = ":heart:"
           > .Spades = ":spades:"
           > .Diamonds = ":diamonds:"
           > .Clubs = ":clubs:"
}

···

On 20 May 2016, 7:15 PM +0800, Charles Constant via swift-evolution <swift-evolution@swift.org>, wrote:

I wrote some code tonight to experiment with this kind of thing. I apologize if it's off-topic for the thread, but it might be useful to others who want to experiment.

//: Playground - noun: a place where people can play

import Cocoa

infix operator • { precedence 180 }
infix operator → { associativity left precedence 70 }
infix operator … { associativity right precedence 60 }

func → <T>( lhs: Bool, rhs: T ) -> T? {
return lhs ? rhs : nil
}

func … <T>( lhs:T?, rhs:T ) -> T {
return lhs != nil ? lhs! : rhs
}

func depends<I,O>( dep:I, _ closure: (I)->(O) ) -> O {
return closure( dep )
}

func • <I,O>( lhs: I, rhs: (I)->(O) ) -> O {
return depends( lhs, rhs )
}

/* Example using "depends" */

let
str:String,
i = 7

str = depends( i ){
$0==2 → "two" …
$0==3 → "three" …
$0==4 → "four" …
"other"
}

/* Example using "•" operator as "depends" */

enum People { case Kurtz, Popescu, Lime, Martins }
enum Order { case First, Second, Third, Unknown }

let
order:Order,
person:People = .Lime

order = person • {
$0 == .Kurtz → .First …
$0 == .Popescu → .Second …
$0 == .Lime → .Third …
.Unknown
}

I also have some trepidation about posting it here, because it might have bugs. I wans't sure what "precedence" and "associativity" should be, for example. But it does make it more convenient to test alternative characters for operators, etc.

On Sat, Apr 9, 2016 at 12:05 AM, Vladimir.S via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On 09.04.2016 9:31, Brent Royal-Gordon wrote:
This design is still very much under development—it hasn't even been reviewed, let alone added to the language. Here's the draft proposal:<https://github.com/jtbandes/swift-evolution/blob/case-enumerable/proposals/0000-derived-collection-of-enum-cases.md&gt;

I'm not saying that this will necessarily be a solution that ends up being accepted—I'm merely saying that yes, it's something people are thinking about and designing; it's just been inactive for a few weeks.

Oh, I see. Thank you for letting know. Just missed "you would be able" in your previous message, did read it as "you are able", so was trying to find this in current Swift version. OK, glad to know that most likely we'll have improvements in enums eterations for Swift 3.0.

_______________________________________________
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

I wrote some code tonight to experiment with this kind of thing. I apologize if it's off-topic for the thread, but it might be useful to others who want to experiment.

//: Playground - noun: a place where people can play

import Cocoa

infix operator • { precedence 180 }
infix operator → { associativity left precedence 70 }
infix operator … { associativity right precedence 60 }

func → <T>( lhs: Bool, rhs: T ) -> T? {
  return lhs ? rhs : nil
}

func … <T>( lhs:T?, rhs:T ) -> T {
  return lhs != nil ? lhs! : rhs
}

func depends<I,O>( dep:I, _ closure: (I)->(O) ) -> O {
  return closure( dep )
}

func • <I,O>( lhs: I, rhs: (I)->(O) ) -> O {
  return depends( lhs, rhs )
}

/* Example using "depends" */

let
  str:String,
  i = 7

str = depends( i ){
  $0==2 → "two" …
  $0==3 → "three" …
  $0==4 → "four" …
  "other"
}

Hmm… replacing -> by ?, and … by : you get:

str = depends( i ){
    $0==2 ? "two" :
    $0==3 ? "three" :
    $0==4 ? "four" :
    "other"
}

which work as is without a need to define new operators.

Dany

···

Le 20 mai 2016 à 07:14, Charles Constant via swift-evolution <swift-evolution@swift.org> a écrit :

/* Example using "•" operator as "depends" */

enum People { case Kurtz, Popescu, Lime, Martins }
enum Order { case First, Second, Third, Unknown }

let
  order:Order,
  person:People = .Lime

order = person • {
  $0 == .Kurtz → .First …
  $0 == .Popescu → .Second …
  $0 == .Lime → .Third …
  .Unknown
}

I also have some trepidation about posting it here, because it might have bugs. I wans't sure what "precedence" and "associativity" should be, for example. But it does make it more convenient to test alternative characters for operators, etc.

On Sat, Apr 9, 2016 at 12:05 AM, Vladimir.S via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On 09.04.2016 9:31, Brent Royal-Gordon wrote:
This design is still very much under development—it hasn't even been reviewed, let alone added to the language. Here's the draft proposal:<https://github.com/jtbandes/swift-evolution/blob/case-enumerable/proposals/0000-derived-collection-of-enum-cases.md&gt;

I'm not saying that this will necessarily be a solution that ends up being accepted—I'm merely saying that yes, it's something people are thinking about and designing; it's just been inactive for a few weeks.

Oh, I see. Thank you for letting know. Just missed "you would be able" in your previous message, did read it as "you are able", so was trying to find this in current Swift version. OK, glad to know that most likely we'll have improvements in enums eterations for Swift 3.0.

_______________________________________________
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 is very similar to Haskell's guard I tried to pitch before, but the community seem to not want it on Swift.

let a | case1 = "case 1"
      > case2 = "case 2"
      > otherwise = "default"

Where otherwise is simply defined as otherwise = True that catches everything (similar to switch default)

On behalf of the OP's:

var description: String {
    case .Hearts:
        return ":heart:"
    case .Spades:
        return ":spades:"
    case .Diamonds:
        return ":diamonds:"
    case .Clubs:
        return ":clubs:"
}

can be:

var description: String {
    return | .Hearts = ":heart:"
           > .Spades = ":spades:"
           > .Diamonds = ":diamonds:"
           > .Clubs = ":clubs:"
}

If we’re going to introduce something like this we should consider having it switch on all parameters, not just self.

···

On May 20, 2016, at 10:18 AM, Angelo Villegas via swift-evolution <swift-evolution@swift.org> wrote:

On 20 May 2016, 7:15 PM +0800, Charles Constant via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>>, wrote:

I wrote some code tonight to experiment with this kind of thing. I apologize if it's off-topic for the thread, but it might be useful to others who want to experiment.

//: Playground - noun: a place where people can play

import Cocoa

infix operator • { precedence 180 }
infix operator → { associativity left precedence 70 }
infix operator … { associativity right precedence 60 }

func → <T>( lhs: Bool, rhs: T ) -> T? {
return lhs ? rhs : nil
}

func … <T>( lhs:T?, rhs:T ) -> T {
return lhs != nil ? lhs! : rhs
}

func depends<I,O>( dep:I, _ closure: (I)->(O) ) -> O {
return closure( dep )
}

func • <I,O>( lhs: I, rhs: (I)->(O) ) -> O {
return depends( lhs, rhs )
}

/* Example using "depends" */

let
str:String,
i = 7

str = depends( i ){
$0==2 → "two" …
$0==3 → "three" …
$0==4 → "four" …
"other"
}

/* Example using "•" operator as "depends" */

enum People { case Kurtz, Popescu, Lime, Martins }
enum Order { case First, Second, Third, Unknown }

let
order:Order,
person:People = .Lime

order = person • {
$0 == .Kurtz → .First …
$0 == .Popescu → .Second …
$0 == .Lime → .Third …
.Unknown
}

I also have some trepidation about posting it here, because it might have bugs. I wans't sure what "precedence" and "associativity" should be, for example. But it does make it more convenient to test alternative characters for operators, etc.

On Sat, Apr 9, 2016 at 12:05 AM, Vladimir.S via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On 09.04.2016 9:31, Brent Royal-Gordon wrote:
This design is still very much under development—it hasn't even been reviewed, let alone added to the language. Here's the draft proposal:<https://github.com/jtbandes/swift-evolution/blob/case-enumerable/proposals/0000-derived-collection-of-enum-cases.md&gt;

I'm not saying that this will necessarily be a solution that ends up being accepted—I'm merely saying that yes, it's something people are thinking about and designing; it's just been inactive for a few weeks.

Oh, I see. Thank you for letting know. Just missed "you would be able" in your previous message, did read it as "you are able", so was trying to find this in current Swift version. OK, glad to know that most likely we'll have improvements in enums eterations for Swift 3.0.

_______________________________________________
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

Thought I'd just followup about the code I posted. It's basically
*horrible* for anything other than toying around. I just clued in that it
doesn't short when it finds a value. Also it causes Playground to stall for
a couple minutes on my machine. Shame :(

PS: It would also have been nice to replace "…" with the built-in "??" but
the precedence doesn't leave any space between 130, and 131 (which is a
pretty good argument to support recently discussed proposal about making
precedence relative)

Do we already have a proposal to add ternary-style *custom* operators (ie:
in addition to infix/prefix/postfix)? I would settle for that, if none of
the "switch assignment" or "multiary ternary" proposals make it into Swift
4.

Good grief. I think you're right.

Some how, a long time ago, I got it into my head that the order in which
each part of the ternary got evaluated would cause problems for this kind
of thing.

I've had a huge blindspot and I've been railing on the list for something I
don't need for weeks.

Wow, I couldn't be more embarassed.

But I'm happy too, because I can go ahead and just use a chained ternary.

Sorry all, and thanks.

···

On Mon, May 23, 2016 at 6:26 PM, Dany St-Amant <dsa.mls@icloud.com> wrote:

Le 20 mai 2016 à 07:14, Charles Constant via swift-evolution < > swift-evolution@swift.org> a écrit :

I wrote some code tonight to experiment with this kind of thing. I
apologize if it's off-topic for the thread, but it might be useful to
others who want to experiment.

//: Playground - noun: a place where people can play

import Cocoa

infix operator • { precedence 180 }
infix operator → { associativity left precedence 70 }
infix operator … { associativity right precedence 60 }

func → <T>( lhs: Bool, rhs: T ) -> T? {
return lhs ? rhs : nil
}

func … <T>( lhs:T?, rhs:T ) -> T {
return lhs != nil ? lhs! : rhs
}

func depends<I,O>( dep:I, _ closure: (I)->(O) ) -> O {
return closure( dep )
}

func • <I,O>( lhs: I, rhs: (I)->(O) ) -> O {
return depends( lhs, rhs )
}

/* Example using "depends" */

let
str:String,
i = 7

str = depends( i ){
$0==2 → "two" …
$0==3 → "three" …
$0==4 → "four" …
"other"
}

Hmm… replacing -> by ?, and … by : you get:

str = depends( i ){
    $0==2 ? "two" :
    $0==3 ? "three" :
    $0==4 ? "four" :
    "other"
}

which work as is without a need to define new operators.

Dany

/* Example using "•" operator as "depends" */

enum People { case Kurtz, Popescu, Lime, Martins }
enum Order { case First, Second, Third, Unknown }

let
order:Order,
person:People = .Lime

order = person • {
$0 == .Kurtz → .First …
$0 == .Popescu → .Second …
$0 == .Lime → .Third …
.Unknown
}

I also have some trepidation about posting it here, because it might have
bugs. I wans't sure what "precedence" and "associativity" should be, for
example. But it does make it more convenient to test alternative characters
for operators, etc.

On Sat, Apr 9, 2016 at 12:05 AM, Vladimir.S via swift-evolution < > swift-evolution@swift.org> wrote:

On 09.04.2016 9:31, Brent Royal-Gordon wrote:

This design is still very much under development—it hasn't even been
reviewed, let alone added to the language. Here's the draft proposal:<
https://github.com/jtbandes/swift-evolution/blob/case-enumerable/proposals/0000-derived-collection-of-enum-cases.md
>

I'm not saying that this will necessarily be a solution that ends up
being accepted—I'm merely saying that yes, it's something people are
thinking about and designing; it's just been inactive for a few weeks.

Oh, I see. Thank you for letting know. Just missed "you would be able" in
your previous message, did read it as "you are able", so was trying to find
this in current Swift version. OK, glad to know that most likely we'll have
improvements in enums eterations for Swift 3.0.

_______________________________________________
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