[swift-evolution] ternary operator ?: suggestion

[Charles Constant]

I can't stop fiddling around with this... so here's another minor
variation. My new new favourite, if we're doubling down on the ternary.

We could start with Paul's ternary example... but it seems more in keeping
to me, with the existing ternary, to use a colon as a separator. If we do
that, an exclamation point seems appropriate, and pretend that it's just
how a ternary expression behaves when it's testing something extra-ternary
(like a n enum with four possible cases)

// Syntax when the value you’re testing is a Boolean

let val = boo ? 0xFF0000 : 0x00FF00


// Syntax when the value you’re testing is not Boolean

let val = color ? ( .Red ! 0xFF0000 ) : ( .Green ! 0x00FF00 ) : ( .Blue !
0x0000FF ) : ( _ ! 0xFFFFFF )


// … Parens are not required, but probably unwise unless you format on
multiple lines. Eg:

let val = color ?

.Red ! 0xFF0000 :

.Green ! 0x00FF00 :

.Blue ! 0x0000FF :

_ ! 0xFFFFFF

I actually like this a lot because it's concise, and aesthetically in
harmony with the normal ternary.

There's obvious downsides to using an exclamation point in Swift, but I
think it's still pretty nice.








On Tue, Jan 5, 2016 at 11:41 PM, Paul Ossenbruggen via swift-evolution <
swift-evolution at swift.org> wrote:

> Heh, one other thought. Pretty sure this was rejected by the switch
> statement but if keeping it concise for expressions is a goal then _ might
> make sense for the default case especially with this form. :-)
>
> let fh = ?(color, .Red: 0xFF0000 // only one expression can be the result
> here so case is unnecessary.
>                   .Green: 0x00FF00
>                   .Blue: 0x0000FF
>                   _: 0xFFFFFF) // default is always last, unless all
> cases are handled.
>
> I agree with it being rejected for the statement form, but kinda makes
> sense here.
>
> On Jan 5, 2016, at 10:50 PM, Paul Ossenbruggen <possen at gmail.com> wrote:
>
> The thing I don’t like is the repeated use of case. and default. This, I
> think makes the expression longer than it needs to be. For expressions it
> is not necessary because you only have one expression which returns one
> value, where as in a statement you have multiple statements following it,
> so it is necessary to separate the cases with the word “case”. I think
> trying to reduce clutter is important.
>
> For example, statements have to deal with multiple statements per case.
>
> let color = Colors.Red
> // hello
> let res : Int
> switch color {
>     case .Red:
> res = 0xFF0000
> print(res) // case is necessary here to separate statement lists.
>     case .Green:
> res =  0x00FF00
> print(res)
>     case .Blue:
> res = 0x0000FF
> print(res)
> default:
>     res = 0xFFFFFF
> }
>
> This is why I went down the path of trying to group it with parenthesis
> and optionally remove the word case. I know it may seem a little less like
> a "switch" but I think having to write out “case" over and over is not
> great when it does not serve the same purpose as it does in the statement
> form. So in the compact form:
>
> let fh = ?(color, .Red: 0xFF0000 // only one expression can be the result
> here so case is unnecessary.
>                   .Green: 0x00FF00
>                   .Blue: 0x0000FF
>                   : 0xFFFFFF) // default is always last, unless all cases
> are handled.
>
>
> This seems more light and more and just as understandable as Thorsten's
> suggestion. (Note: I keep playing with the separators because the feedback
> was, my latest suggestions were not Swift like). Also, it is possible to
> drop the “case" in this structure and it can be read more like a function
> if desired. My suggestion also supported this form but its only advantage
> is that it looks more like a “switch", there may be value in that but I
> think conciseness and less clutter should win:
>
> let fh = ?(color, case .Red: 0xFF0000
>                   case .Green: 0x00FF00
>                   case .Blue: 0x0000FF
>                   default: 0xFFFFFF)
>
> Not sure though if people don’t like having alternatives forms though.
>
> I think there is value in having a consistent way of doing index based as
> well as boolean based expressions as I have suggested in my proposal. I
> know that is a harder thing to push for but I think it is a win. I have
> backpedaled on some of my weirder character choices here so it more like
> the ternary.
>
> let fb = ?(pickOne, “A", "B", "C", "D", "E", "F", "G” : "Z")
> let fe = ?(truthy == truth, “unlikely” : “likely")
>
> If you look at these suggestions above, I have only moved one ? added a
> comma, and added parenthesis to the ternary. I think these latest
> suggestions look more like Swift and more like the ternary than my last
> email.
>
> If it is really preferred the control value could be moved outside the
> parens but I think it makes it harder to find the beginning and end of the
> ternary and it does not have the advantage of the function like feel to
> it:.
>
> let fe = truthy == truth ?(“unlikely” : “likely")
>
> let fh = color ?( .Red: 0xFF0000
>                   .Green: 0x00FF00
>                   .Blue: 0x0000FF
>                   : 0xFFFFFF)
>
> finally we could drop the parenthesis all together and the ternary is back
> in original form, which results in Thorsten’s suggestion minus the cases,
>
> let fe = truthy == truth ? “unlikely” : “likely"
>
> let fh = color ? .Red: 0xFF0000
>                  .Green: 0x00FF00
>                  .Blue: 0x0000FF
>                  : 0xFFFFFF
>
> I think the parenthesis and the control inside the construct really help
> and this may be hard to parse without the grouping the parenthesis
> provides. I don’t think we are that far apart though.
>
> - Paul
>
>
>
> _______________________________________________
> 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/20160106/325ac919/attachment.html>