[swift-evolution] ternary operator ?: suggestion

[James Campbell]

We could do a Ruby and return the last value seen in a swift block. :)

let a = switch(value)
{
  case is Int:
  "Frodo"
}

On Wed, Jan 6, 2016 at 2:01 PM, Charles Constant via swift-evolution <
swift-evolution at swift.org> wrote:

> 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
>>
>>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>


-- 
 Wizard
james at supmenow.com
+44 7523 279 698
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160108/f6ac6010/attachment.html>