[swift-evolution] ternary operator ?: suggestion

Paul Ossenbruggen possen at gmail.com
Sun Dec 20 11:22:59 CST 2015


Yes definitely. This should be in the proposal. Thanks.

> On Dec 20, 2015, at 8:53 AM, Stephen Canon <scanon at apple.com> wrote:
> 
> Paul, does the proposed operator short-circuit like ternary does (i.e. is only the active case evaluated)?
> 
> – Steve
> 
>> On Dec 19, 2015, at 11:42 AM, Paul Ossenbruggen via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> Thanks, great feedback!
>> 
>> Good point about the floats, that is definitely a hole in my proposal! I will update it with that.
>> 
>> To the list form being confusing, I would definitely like to know if others agree that having the two forms is confusing. The list form would be zero based. I would definitely drop it from the proposal if it would lead to it being declined but I think it is nice because it is concise and serves a valuable purpose of choosing among many choices without having to write out each case. 
>> 
>> The alternate form,  in alternatives considered, a variant of Vestor Godfied’s suggestion, is:
>> 
>> if (x==y : true, false)
>> switch (control : .North:”N”, .South:”S”, .East:”E”, .West:”W”, default:” “) 
>> select (control : “A”, “B”, “C”, default:”D”) 
>> 
>> may be preferred if others agree that it is confusing to have the list form and the case form together. Since Swift leaves parenthesis available around if and switch statements, the parenthesis colon sequence could be used to distinguish the statement and expression form. One thing I really don’t like about it is, that Swift finally solved the problem people running the space up against the  parenthesis, something that had bothered me for some time, this would make the practice ingrained if(control : true, false) would become the norm. I suppose in this case it would make sense though. 
>> 
>> Or if making it even more explicit we could combine the forms. 
>> 
>> if? (x==y : true, false)
>> switch? (control : .North:”N”, .South:”S”, .East:”E”, .West:”W”, default:” “) 
>> select? (control : “A”, “B”, “C”, default:”D”) 
>> 
>> I expect that that may be more controversial though. As it then steps into the optionals area. 
>> 
>> With both these options we lose some conciseness. So I still prefer the form in the proposal. 
>> 
>> - Paul
>> 
>>> On Dec 19, 2015, at 2:43 AM, Conrad Kutsch via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>> Hey, I really like the new proposal, gets a +1from me! Especially the case part makes it good to use. I would just leave out the Integer part because it can be confusing and misleading. Do you start counting at 1? Or at 0? MinInt? It’s just super error-prone if you don’t write the number before it.
>>> 
>>> ?(charNum : 0: "A", 1: "B”, ...
>>> might be OK as it would get rid of the many case statements but then again, is this only working for Int or also for float?
>>> 
>>> 
>>> 
>>>> On 19 Dec 2015, at 01:56, Paul Ossenbruggen via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>> 
>>>> Thanks for your support! 
>>>> 
>>>> I think parenthesis are preferred because braces are for bracketing lists of statements. Statements may or may not return values. 
>>>> 
>>>> Having the conditional on the inside of the parens helps to show the begging of the demux operator rather than a floating conditional which is a common complaint with the ternary operator. 
>>>> 
>>>>> On Dec 18, 2015, at 3:46 PM, Charles Constant <charles at charlesism.com <mailto:charles at charlesism.com>> wrote:
>>>>> 
>>>>> +1 
>>>>> 
>>>>> I'd be very happy with your new proposal too. I still prefer sticking the value we're using as a key outside of the parens, but it's a minor quibble. Also I can't figure out if parens or curly braces are more appropriate. Does it make more sense for the expression to look like a tuple or a closure? I'm not sure.
>>>>> 
>>>>> Anyhow, I'm good with your new proposal.
>>>>> 
>>>> 
>>>> _______________________________________________
>>>> 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>
>>> 
>>> _______________________________________________
>>> 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>
>> 
>>  _______________________________________________
>> 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/20151220/73ff0c4f/attachment.html>


More information about the swift-evolution mailing list