[swift-evolution] ternary operator ?: suggestion

[Alex Lew]

Yes, I'm of two minds about adding *case*.

On the one hand, it is much more consistent with the rest of the
language. *case
*is used everywhere else in Swift that pattern matching is allowed. (if
case..., for case..., while case...) I think this is a strong argument that
it should be used in pattern matching expressions too.

On the other hand, what is the point of pattern matching expressions if not
to be brief? They don't enable you to do anything you couldn't do before
with a switch and assignment, right? So it seems like a priority should be
getting them to look nice and readable, which the comma syntax does. It
actually doesn't look too bad with both case and comma:

let thisColor = thatColor ? case .Blue: .Red, case .Green: .Blue, default:
.Yellow

And on the third hand, it still does save you a good amount of space even
if you're not all on one line. Compare

let thisColor: Color
switch thatColor {
    case .Blue:
        thisColor = .Red
    case .Green
        thisColor = .Blue
    default:
        thisColor = .Yellow
}

with

let thisColor = thatColor ?
    case .Blue: .Red
    case .Green: .Blue
    default: .Yellow





On Sun, Dec 6, 2015 at 2:19 PM, Kevin Lundberg via swift-evolution <
swift-evolution at swift.org> wrote:

> Ostensibly, case may not be necessary if you could delimit each case on
> one line with something (perhaps a comma, or something else if that would
> not fit well within the grammar):
>
> let thisColor = thatColor ? .Blue: .Red, .Green: .Blue, .Red: .Green,
> default: .Yellow
>
> On Sun, Dec 6, 2015, at 01:57 PM, Paul Ossenbruggen via swift-evolution
> wrote:
>
> I like this too, seems more powerful.  Also, would single line expressions
> be allowed?  If not would case be required for example:
>
> let myFavoriteColor = yourFavoriteColor ?
>     case .Blue: .Red
>     case .Green: .Blue
>     case .Red: .Green
>     default: .Yellow
>
>
>
> On Dec 6, 2015, at 9:11 AM, Sean Heber via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> I really like this train of thought. +1
>
> l8r
> Sean
>
> On Dec 6, 2015, at 11:02 AM, Alex Lew via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> What if we left the if { ...} else { ... } syntax alone (as a statement),
> and updated the ternary expression to be a more general pattern matching
> expression (closer to "switch")? Something like
>
> let x = condition ?
>    true: "Hello"
>    false: "Goodbye"
>
> let x = optionalValue ?
>    .Some(let unwrapped): "Hello, \(unwrapped)"
>    .None: "To Whom It May Concern"
>
> let myFavoriteColor = yourFavoriteColor ?
>     .Blue: .Red
>     .Green: .Blue
>     .Red: .Green
>
> let quadrant = (x, y) ?
>     let (x, y) where x < 50 && y < 50: "top left"
>     let (x, y) where x < 50 && y > 50: "bottom left"
>     let (x, y) where x > 50 && y < 50: "top right"
>     default: "bottom right"
>
> The colon comes from the fact that this is sort of a light-weight
> expression-based "switch" statement, where each branch can only contain an
> expression, not a series of statements.
>
> This is very similar to pattern matching expressions in languages like
> Haskell, ML, and Coq.
>
> On Sun, Dec 6, 2015 at 11:25 AM, Thorsten Seitz <thorsten.seitz at web.de> wrote:
>
>
>
>
> Am 06.12.2015 um 01:28 schrieb Alex Lew via swift-evolution <
> swift-evolution at swift.org>:
>
> I don't think you can just get rid of the if statement in favor of an
> expression. You still want to be able to do this:
>
> if (condition) {
>     funcWithSideEffectsThatReturnsInt()
> } else {
>     funcWithSideEffectsThatReturnsString()
> }
>
> but that's not a valid expression (what is its type?).
>
>
>
> That would actually be no problem if Swift’s type system would have union
> types (Ceylon has union and intersection types which are quite awesome and
> enable lots of nice things quite naturally, see
> http://ceylon-lang.org/documentation/1.2/tour/types/).
>
> In that case the type of such an expression would just be the union of
> both types, which is written Int | String in Ceylon.
>
>
> -Thorsten
>
>
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> 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
>
>
> *_______________________________________________*
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> Untracked with Trackbuster <https://trackbuster.com/?sig>
>
> _______________________________________________
> 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/20151206/2b983bcd/attachment.html>