[swift-evolution] ternary operator ?: suggestion

Sun Dec 13 12:37:50 CST 2015

Replacing constructs like

let x = condition ? 0 : 1

with

let x = if condition { 0 } else { 1 }

is very unlikely to make working with Swift any easier.

On Sun, Dec 13, 2015 at 7:18 PM, Dennis Lysenko <dennis.s.lysenko at gmail.com>
wrote:

> Just wanted to add, in regards to the argument of "why use 'then' rather
> than keeping 'if condition { A } else { B }'?": besides my personal opinion
> that inline braces look out-of-place, braces behave specially in xcode and
> are notorious for screwing up indentation. For example, since swift was
> released, multiple non-trailing closure arguments to a single function call
> (e.g. MagicalRecord.saveWithBlock) are indented inconsistently, with the
> second closure one indentation level higher than the first. More
> generally/summarily, braces carry special indentation rules that do not
> necessarily suit expressions.
>
> On Sun, Dec 13, 2015, 12:17 PM Paul Ossenbruggen via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>> On Dec 13, 2015, at 6:11 AM, Marc Knaup <marc at knaup.koeln> wrote:
>>
>> I also have no preference yet so I'll just throw in some thoughts.
>>
>> ** Existing Code **
>> The removal of the ternary operator would likely affect a lot of existing
>> code.
>> A quick search for " ? " (with spaces) over a large app of our team
>> yields 304 results.
>>
>> Two simpler examples:
>>
>> [
>>   "With Conditions":            hasReport ? "yes" : "no",
>>   "With Image":                 hasImage ? "yes" : "no",
>>   "With Message":               hasMessage ? "yes" : "no",
>>   "Shared on Facebook Profile": sharedOnFacebookProfile ? "yes" : "no",
>>   "Shared in Facebook Group":   sharedOnFacebookGroup ? "yes" : "no",
>>   "Shared on Facebook Page":    sharedOnFacebookPage ? "yes" : "no"
>> ]
>>
>> view1.alpha = editing ? 1 : 0
>> view2.alpha = editing ? 1 : 0
>> view3.alpha = editing ? 0 : 1
>> view4.alpha = editing ? 1 : 0
>>
>> I am not sure using if…then…else would make this better to read &
>> understand or worse.
>>
>>
>> there seems to be a lot of people who dislike ternary operators. Other
>> languages also are similar in dumping ternary.
>>
>>
>> ** Keyword then **
>> Making then a keyword would also cost us another word so that change
>> needs to be carefully considered.
>> In our large app I found just a single instance where then was used for
>> a variable's name:
>>
>> func reloadConfigurationAndThen(then: () -> Void) { … }
>>
>> Promises use the word then rather extensively: https://promisesaplus.com
>>
>>
>> Good point. Will think about it.
>>
>> On Sun, Dec 13, 2015 at 2:45 PM, Matthew Johnson via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>>> I'm not quite sure how I feel about this specific proposal yet but in
>>> general I do want to see conditional expressions and removal of the ternary
>>> operator.
>>>
>>> I would like to see "else if" included in whatever we adopt as the final
>>> solution.  Is there a reason this is omitted from this proposal?  I
>>> apologize if that was discussed in the thread.  I haven't followed every
>>> post.
>>>
>>> Sent from my iPad
>>>
>>> On Dec 12, 2015, at 11:54 PM, Paul Ossenbruggen via swift-evolution <
>>> swift-evolution at swift.org> wrote:
>>>
>>> Hello All,
>>>
>>> Been sick in bed all day, but decided to try to be productive…
>>>
>>> I did a rough draft of a proposal for implementing if expressions and
>>> switch expressions based upon the discussions we had here. I have tried to
>>> keep the scope of the changes as small as possible,  only added one keyword
>>> and kept things as similar to the existing language constructs as possible.
>>> If anyone wants to help me with this, or has feedback, please let me know,
>>>
>>> https://github.com/possen/swift-evolution/blob/master/0020.md
>>>
>>> Thanks,
>>> - Paul
>>>
>>>
>>>
>>> On Dec 12, 2015, at 3:51 PM, Paul Ossenbruggen <possen at gmail.com> wrote:
>>>
>>> Implied in using the  “then", if…then…else would aways require “else"
>>> when using “then” similar to how “guard" requires “else”. This  will help
>>> to make the difference between statements and expressions clear.
>>>
>>> let x = If cond then X else Y
>>>
>>> is the full form, where “else" can not be omitted.
>>>
>>> On Dec 12, 2015, at 12:59 PM, Paul Ossenbruggen <possen at gmail.com>
>>> wrote:
>>>
>>>
>>>
>>> On Dec 12, 2015, at 12:37 PM, Andrey Tarantsov via swift-evolution <
>>> swift-evolution at swift.org> wrote:
>>>
>>> 1. I would really hate to explain to someone when *if* needs a *then*
>>> and when it doesn't. That's the sort of inconsistency that shouldn't be
>>> added lightly.
>>>
>>>
>>> agreed definitely want to be careful with that. I think with braces
>>> meaning statements that differentiation can be made clear. I would
>>> certainly start with statements when describing, just as you usually don’t
>>> talk about the ternary operator until later.
>>>
>>> 3. If we can somehow solve all of this, I think I'll be +1 for replacing
>>> (A ? B : C) with some sort of (*if* A *then* B *else* C).
>>>
>>>
>>> Yes that would be great.
>>>
>>>
>>> 4. Generally, I wonder how hard would it be for all statements to be
>>> usable as expressions? Why didn't Swift go that way from the start?
>>>
>>>
>>> The biggest problem statement is you don’t need to exhaustively specify
>>> every outcome:
>>>
>>> if cond {
>>> print(“hello”)
>>> }
>>>
>>> whereas in an expression you have to specify what happens in the else.
>>>
>>> let say = if cond then “hello” else “goodbye"
>>>
>>> unless you go seriously off the deep end:
>>>
>>> let say = if cond then “hello”
>>>
>>>  “say" then becomes an optional, *shudder*
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>>>
>>>
>>
>> _______________________________________________
>> 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/20151213/4eeb430c/attachment.html>