[swift-evolution] ternary operator ?: suggestion

[Paul Ossenbruggen]

I have definitely been trying to keep this in mind with these designs. Compact representations should be possible.


> On Dec 22, 2015, at 10:07 AM, Jordan Rose <jordan_rose at apple.com> wrote:
> 
> I think this is a good point. We definitely want to keep the boolean ternary operator compact for the simple cases, and that may be at odds with a general switch expression (with multi-case pattern match).
> 
> Jordan
> 
> 
>> On Dec 22, 2015, at 10:03 , Thorsten Seitz via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> Sorry, but I find all these very unreadable.
>> 
>> IMO trying to create one-line switch expressions is a non-goal as I would always write switch expressions in multiple lines, one per case. Anything else I personally consider unreadable.
>> 
>> -Thorsten 
>> 
>> Am 22.12.2015 um 09:11 schrieb Paul Ossenbruggen via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>>:
>> 
>>> All,
>>> 
>>> I have continued work on my proposal. I am trying to gauge whether people feel that this syntax which is currently in the proposal is better or worse than the last two variations.  The current proposal syntax:
>>> 
>>> let a = ?(x == y: a, b)
>>> let b = ?(colorEnum : Red: 0xFF0000, .Green: 0x00FF00, .Blue: 0x00000FF, default: 0xFFFFFF)
>>> let c = ?(pickOne : “A”, “B”, “C:, default: “Z”)
>>> 
>>> The preceding is the unified ?( operator approach and is the closest to the existing ternary. but expands its capabilities to support more types of control than just bool. It is the most concise and adds no new keywords. It determines the kind of expression based upon the format inside the braces. The next version is the full keyword approach which has the same capabilities but separates each kind out:  
>>> 
>>> let a = if(x == y then "A" else "B")
>>> let b = switch(colorEnum then .Red: 0xFF0000, .Green: 0x00FF00, .Blue: 0x00000FF, default: 0xFFFFFF) 
>>> let c = select(pickone then "A", "B", "C", default: "Z”)
>>> 
>>> or to avoid a new keyword and be slightly more concise. This one is the hybrid approach:
>>> 
>>> let a = if(x == y : "A" else "B")
>>> let b = switch(colorEnum : .Red: 0xFF0000, .Green: 0x00FF00, .Blue: 0x00000FF) 
>>> let c = select(pickone : "A", "B", "C", default: "Z")
>>> 
>>> Note that the use of parenthesis outside the entire expression in these is to emphasize that these are expressions, can be read almost like a regular function, they serve to group the entire expression, and they would be required around the full expression only the leading keyword is outside. This will disambiguate it from the statement form. Braces are for statements and parenthesis for expressions. Putting the “then”and “else” part inside the parens also avoids the problem of “then” with the following format:
>>> 
>>> x = if cond then A else B
>>> 
>>> With this we would have support “then” in the “if" statement form and it is hard to tell it from the statement form. By putting it in parenthesis, we can put whatever we want in there. 
>>> 
>>>  The advantage of the second or third approach is the syntax would be custom to each kind so additional checking could be performed to ensure it is correct for the keyword provided. The keywords would be context sensitive so may not interfere with other uses of it. 
>>> 
>>> These last two possibilities may address some of the issues that Jordan Rose brought up…the first is the double colon, for the separator and for the cases. The issue he mentioned second is that he did not feel my proposal addressed any of the problems with the ternary, and third he wants to keep the ? just for optionals. If the colon to separate the control, in the last one is not good, I am open to suggestions for other separators, but keep in mind, that goes even further from the ternary which may or may not be a good thing.
>>> 
>>> I think I would be happy with any of these. If the consensus is that either of the last two are preferable, I will rewrite the proposal with that in mind. Please let me know if you have any questions or have other suggestions. 
>>> 
>>> Thanks,
>>> - Paul
>>> 
>>> For latest version of proposal and see Alternatives Considered section for more details on this: 
>>> https://github.com/possen/swift-evolution/blob/master/proposals/0024.md <https://github.com/possen/swift-evolution/blob/master/proposals/0024.md>
>>> 
>>> _______________________________________________
>>> 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/20151222/38123e30/attachment.html>