[swift-evolution] [Idea] Find alternatives to `switch self`

[Matthew Johnson]

> On May 20, 2016, at 10:18 AM, Angelo Villegas via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 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 "♥️"
>     case .Spades:
>         return "♠️"
>     case .Diamonds:
>         return "♦️"
>     case .Clubs:
>         return "♣️"
> }
> 
> can be:
> 
> var description: String {
>     return | .Hearts = "♥️"
>            | .Spades = "♠️"
>            | .Diamonds = "♦️"
>            | .Clubs = "♣️"
> }

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

> 
> On 20 May 2016, 7:15 PM +0800, Charles Constant via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at 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 at swift.org <mailto:swift-evolution at 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 <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 at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160520/1d03dd48/attachment.html>