[swift-evolution] ternary operator ?: suggestion

Dennis Lysenko dennis.s.lysenko at gmail.com
Sun Dec 13 12:18:57 CST 2015


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/65523389/attachment.html>


More information about the swift-evolution mailing list