[swift-evolution] ternary operator ?: suggestion

Sun Dec 13 13:45:50 CST 2015

Coming up with a special way to return from closures/blocks is being
discussed in the remove forEach thread. It may even need its own thread
since it would affect so much of the language.

On Sunday, December 13, 2015, Andrew Brown via swift-evolution <
swift-evolution at swift.org> wrote:

> I agree, but there seems to be a lot of support for statements as
> expressions for some reason. That's not something I'd be keen to move
> towards quickly but if we need to go there, how about a more general
> solution.
>
> Let's give every statement a builtin 'return' variable - I'll use _ in the
> example below but I don't think it's really appropriate.
>
> let x = if condition {
>     _ = value1
>   } else {
>     _ = value2
>   }
>
> let width = if condition {_ = 1920} else {_ = 640}
>
> With a default assumption that _ = void if the default, if no assignments
> are used, we can ensure type checking and catch cases where not all paths
> correctly assign to _
>
> ABR.
>
> On 13 Dec 2015, at 18:37, Marc Knaup via swift-evolution <
> swift-evolution at swift.org
> <javascript:_e(%7B%7D,'cvml','swift-evolution at swift.org');>> wrote:
>
> 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
> <javascript:_e(%7B%7D,'cvml','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
>> <javascript:_e(%7B%7D,'cvml','swift-evolution at swift.org');>> wrote:
>>
>>> On Dec 13, 2015, at 6:11 AM, Marc Knaup <marc at knaup.koeln
>>> <javascript:_e(%7B%7D,'cvml','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
>>> <javascript:_e(%7B%7D,'cvml','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
>>>> <javascript:_e(%7B%7D,'cvml','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
>>>> <javascript:_e(%7B%7D,'cvml','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
>>>> <javascript:_e(%7B%7D,'cvml','possen at gmail.com');>> wrote:
>>>>
>>>>
>>>>
>>>> On Dec 12, 2015, at 12:37 PM, Andrey Tarantsov via swift-evolution <
>>>> swift-evolution at swift.org
>>>> <javascript:_e(%7B%7D,'cvml','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
>>>> <javascript:_e(%7B%7D,'cvml','swift-evolution at swift.org');>
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>
>>>>
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution at swift.org
>>>> <javascript:_e(%7B%7D,'cvml','swift-evolution at swift.org');>
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>
>>>>
>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> <javascript:_e(%7B%7D,'cvml','swift-evolution at swift.org');>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> <javascript:_e(%7B%7D,'cvml','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/3445715a/attachment.html>