In your first example the switch statement is evaluating whether the given tuple of type (_:bool, _:bool) matches another tuple of type (_: bool, y: bool)
The type signature doesn't match. I believe the change would not be additive like you say because it seems like it would require a change in how tuple compare with each other. On Mon, Jan 2, 2017 at 12:00 AM Erica Sadun via swift-evolution < [email protected]> wrote: > Well, it turns out, I was testing it on already established values. The > first of the following two examples works but the second does not. > > switch (true, y: false) { > case (true, y: false): print("tf") > default: print("nope") > } > > let testTuple2 = (true, false) > > switch testTuple2 { > // error: tuple pattern element label 'y' must be '_' > case (true, y: false): print("tf") > default: print("nope") > } > > I think this gets a 95% Emily Litella ( > https://en.wikipedia.org/wiki/Emily_Litella). "Nevermind." > > And thanks, Tony, > > -- E > > > On Jan 1, 2017, at 8:49 PM, Tony Allevato <[email protected]> wrote: > > The "after" example you posted seems to work already in Swift today. Is > there something I'm missing? > > > On Sun, Jan 1, 2017 at 7:35 PM David Sweeris via swift-evolution < > [email protected]> wrote: > > > > Sent from my iPhone > > On Jan 1, 2017, at 19:25, Erica Sadun via swift-evolution < > [email protected]> wrote: > > Was helping a friend with some code and got inspired. I decided to throw > this on list to see if there's any traction. > > *Idea*: Introduce optional argument labels to tuples in switch statements > > *Motivation*: Cases can be less readable when pattern matching tuples. > Semantically sugared, optional argument labels could increase readability > for complex `switch` statements by incorporating roles into cases. > > Here's an example before: > > fileprivate func chargeState(for battery: BatteryService) > -> ChargeState > { > switch (battery.state, battery.isCalculating) { > case (.isACPowered, true): > return .calculating(isDischarging: false) > case (.isACPowered, _) where battery.isCharging: > return .charging > case (.isACPowered, _): > return .acPower > case (_, true): > return .calculating(isDischarging: true) > default: > return .batteryPower > } > } > > > and after: > > fileprivate func chargeState(for battery: BatteryService) > -> ChargeState > { > switch (battery.state, *calculating: battery.isCalculating*) { > case (.isACPowered, *calculating: true*): > return .calculating(isDischarging: false) > case (.isACPowered, _) where battery.isCharging: > return .charging > case (.isACPowered, _): > return .acPower > case (_, *calculating: true*): > return .calculating(isDischarging: true) > default: > return .batteryPower > } > } > > > It's a pretty minor change, and I could see it being added to allow case > statements to be more readable with a minimal change to the compiler. I > also have a back-burnered proposal I intend to introduce in Phase 2 that > would introduce Boolean raw value enumerations for flags. > > Thoughts? > > > I can't think of a reason not to do that... +1 > > - Dave Sweeris > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
