[swift-evolution] ternary operator ?: suggestion

Paul Ossenbruggen possen at gmail.com
Wed Jan 6 10:08:11 CST 2016


I see what you are trying to do, because of the colon being both used for switch cases and separators for the ternary and so there needs to be a new character for each case.  I am not sure that putting colons between each case is really necessary though. In my suggestion it is only used in the default case. It may also lead to confusion about when to use the ! since it becomes less “switch” label like. So using commas in the single line form does what I think you were trying to accomplish with the “:”:

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

Commas would be optional so that multiline does not get messy.

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

This looks a lot like a combined ternary and switch. The : is not used for the switch expression because the _ case handles that and it is exhaustive.

I still like the grouping the parens provide in my proposal though and it may be necessary to tell the parser when the switch expression ends.

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

If having the conditional outside is preferred then

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

I don’t think this solves some of the shortcomings of the ternary. One being it is hard to see where they start and end.

	let val = boo == scary  ? 0xFF0000 : 0x00FF00

Visually it is hard to see that the = goes with boo or with boo == scary. But that does mean that in the boolean case we could leave the ternary completely as is. For comparison with the breaking change: 

	let val = ?(boo == scary, 0xFF0000 : 0x00FF00)

it is super clear the grouping here. However it is a breaking change so maybe better to leave it or allow both forms?

> On Jan 6, 2016, at 6:01 AM, Charles Constant <charles at charlesism.com> 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 <mailto: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 <mailto: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 <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <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/0f62cec6/attachment.html>


More information about the swift-evolution mailing list